Archive for the ‘General’ Category

Dealing with Angry People – Tech Talk

January 30th, 2015 by Gareth Wilson

 

In this Tech Talk, Rich Armstrong, our COO and former Support Team Lead, discusses techniques to help you deal with angry people. He covers why anger is, in fact, a gift and talks about the LATTE method of dealing with anger in the right way. The aim of which is to not only solve the customer’s problem but to turn them into a fan.

 

About Fog Creek Tech Talks

At Fog Creek, we have weekly Tech Talks from our own staff and invited guests. These are short, informal presentations on something of interest to those involved in software development. We try to share these with you whenever we can.

 

Content and Timings

  • Introduction (0:00)
  • Serving Frustrated Customers (0:17)
  • Anger is a gift (1:30)
  • LATTE (2:32)
  • Listen (2:48)
  • Acknowledge (5:12)
  • Tell (6:40)
  • Take Action (7:40)
  • Explain (8:28)

 

Transcript

Introduction

We all have to deal with angry people in our lives. I have come across some resources that make it far, far easier for me and I’m going to tell you why.

Serving Frustrated Customers

So, actual anger is much more rare than just frustration. When yo get an angry person on the phone, what it usually is is frustration. They won’t come to you, you aren’t on the phone with them unless they suspect that you can help them in some way. If they go out and start shaking people and start complaining to them, then they get put in jail. If they call you up, then they have some suspicion that you can do something about it.

In that respect then they are kind of like your customer. And so really what we’re talking about here is serving frustrated customers, so surprise, you have entered Customer Service training! But the thing is, you can actually use these techniques no matter whether you are dealing with an external customer or somebody who. You know, I use this on 1x1s if people are angry or frustrated about a given thing at Fog Creek. I will use the same techniques and you can almost 100% use these techniques without anybody knowing, even somebody who knows about them.

Anger is a gift

So, anger is a gift. Rage Against the Machine said it right. It’s a gift that you have to open in the right order. Just like you get a Christmas present, and you tear right into the package you’re going to make some people mad. You need to actually open the card, and when you open the card look at it and say ‘ooh, that’s really nice of you to say’ even though you really want to get into the gift. And then your choice, you can either rip off the wrapping or take it off nicely. But, inside that package is a gift. And the secret here is that the bigger the anger, the bigger the gift. What I’ve found is that the people who contact our company who are really, really, super angry are really, really, super invested in using our products. Otherwise, we couldn’t have gotten them that angry, they would have just gone away. And when people are really, really, super angry, then they’re really, really super-invested and if you can solve their problems and make them happy, then you can really turn them into fans.

LATTE

So, LATTE. This is a simple mnemonic that you can use in a frustrating situation. It actually comes from customer service training at Starbucks. Listen, acknowledge, tell, take action and explain. I’m going to go through those one at a time.

Listen

Listening is not just shutting up, although shutting up works really well. There are some things which you can do called Active Listening. I’m going to talk about prompting last because it can be really fun. Countdowns is one thing, if somebody is really exercised on the phone, basically yelling at me, then will just wait until they have stopped talking and then I’ll count to 4 and then I’ll do something. Just to make sure you give ample space so that they can really start to work out some of the anger and feel heard.

Restating is just a simple Active Listening thing. You want to be a little bit careful of it because it can seem facile.

Prompting is literally just saying the exact thing they’ve been saying. The simplest method of prompting is saying the exact last thing that came out of their mouth. And it is a way of saying to the person, of queuing the person to say ‘I’m listening, I’ve understood what you have just said, please continue.’ And it’s a very subtle way of doing so. It can feel really alien if you are not used to doing it. When I was at Google we had a customer service exercise where we did some prompting exercises. And we actually took this away. So, if John was saying ‘you know, my food arrived late and the server wasn’t very nice to me.’ I would wait a couple of seconds and say ‘the server wasn’t very nice to you?’ Maybe it’s a question, maybe it’s a restatement. Usually, the person will just pick up on that prompt and talk. So it’s a way to get people to continue talking until their anger has really tailed off a little bit.

You can actually play a game with your friends that’s hilarious. If somebody is holding the floor for a long time, please don’t play this game with me. You literally just repeat the last thing they say and figure out how long you can keep them talking for before they realise that you are acting weird. You will be amazed.

Acknowledge

So next up is acknowledging. This is making the person feel heard, the first active thing that you do. This can be a little bit touchy, you want to pitch your acknowledgement to the level of the problem. If someone calls in and says I want my password reset, then don’t say ‘oh well, if you need your password reset sir, then we’re going to get right on that!’ that’s an over-acknowledgement which might been seen as mocking. If you don’t acknowledge a big problem enough then that person can feel like they are not getting through to you. So it’s a really big issue. And for instance if you have been trained to say ‘thank you for giving me the opportunity to solve your problem today, we are going to collect some more information from you,’ then they are going to continue to get more and more frustrated. And so what you want to do is called ‘pace and lead.’ You want to match your level of emotion to their level of emotion. So you might say ‘oh jeez, that’s not very good, let’s take a look and see what we can do.’ So in that one sentence I’ve been able to show that they’ve been able to get an emotional rise out of me and then I started to say the problem in terms of collaboration and cooperation. And this is something that you will hear, when you learn to recognise it, on the phone.

Tell

So now you’re going to be very tempted once you get to that point, once you know what you’re going to do, to run off and do the thing that’s going to fix the problem. This is a big mistake. I think we’ve all been in a situation where you’re in a restaurant and you say ‘my food hasn’t arrived’ and the server just turns around and runs away from the table, like back towards the kitchen to check on your food or something. And it feels like an odd interaction because you don’t know what’s happening. Did you just run away? One of the best things you can do is give people a course of action and when you’re giving them a course of action say ‘and if that doesn’t work then I’m going to try this.’ People want to see context, people want to see that they are in a process, they want to see evidence of movement.

Take Action

Now you can take action. And often for me in a 1×1, if I’m talking to someone who is frustrated, then the taking of action is just writing it down. In Rands in Repose’ Managing Humans, it says one of the things that you have to do is when you are doing 1x1s with people is, you have to write everything down. ‘So yeah I’m going to do something about that.’ Just the act of writing it down can be all you need to do to take action. Sometimes things can be more complex. This is the moment when you can put them on hold, this is the moment when you can send the email, and this is the moment when the urgency has sort of bled out of the interaction.

Explain

And now is when you get to explain. If you jump ahead to explaining, often times when someone says, when someone brings you a problem and they are frustrated, your immediate first response will be to explain to them to give them a reason for that. It is the worse possible thing that you can do. For various reasons that I don’t need to go in to, or I won’t go in to now. It can really, really rankle people if you say like ‘well, you walked right in after a big party’ in a restaurant ‘so that is why your food is late’. And it’s like ‘sorry, excuse me for arriving at your restaurant with money in my hands, right?’

So again, anger is a gift, this is a present that when you unwrap it you will actually find a friend, a fan, and you can use this technique to make actual connections to people who otherwise you wouldn’t make a connection with. And usually, after you’ve gone through this process, if you go through it in the right steps, the deeper the interaction then the more reward you get.

Random Meet-ups to Maintain Company Culture with Remote Workers

January 27th, 2015 by Gareth Wilson

Company culture is really important. It’s something we know you have to actively work on to build and maintain. This is especially true when you have remote employees. More than half of Fog Creek’s staff now work remotely. This change has come about pretty quickly, with the move to allow remote workers being less than two years ago. Since then we’ve taken on many new hires and existing staff have moved to working remotely too. It has forced us to re-think a few things. The old bag of tricks, like private offices and catered lunches etc. don’t help remote employees. So we set about coming up with new ways to make sure everyone still feels involved and part of a great company.

Meet and Greet Random People in your Organization

One initiative we’re trying at the moment is CoffeeTime. CoffeeTime is an app, created in less than a day by Daniel, one of our developers. It works by pairing people up randomly, to meet and greet each other, often with someone you may not normally interact with. It doesn’t matter what level in the org chart, or role each person plays. Anyone can be matched up for a 30-minute chat (though people can choose to opt-out, of course). It aims to encourage the cross-team communication and serendipitous learning which otherwise happens naturally when co-workers share an office.

At its heart is the idea that the most important things to learn are often those you didn’t even know you needed to. By making more connections with the people you work with, it increases the likelihood that you’ll have access to someone who can help you further down the line. Maybe that person is having a similar problem or has experienced it before and can point you in the right direction. Or maybe you just end up making a new friend!

Either way, once a week CoffeeTime runs and you’re matched up with someone else in the organization. Each of you receives an email telling you who that person is. You then take it from there and arrange to meet in person or over a Hangout, to eat lunch or just chat.

coffeetime_visual

So How is it Working Out?

Well, it will take time to tell if it works and whether it is something we’ll stick with. But the initial feedback has been positive. It has resulted in a bunch of meet-ups between people who hadn’t previously had the opportunity to speak to each other much before.

coffeetime_feedback

Try It Out – CoffeeTime is Open Source

Interested in trying it out yourself? Sure thing, we’ve open-sourced it. It’s written in Ruby, runs on Heroku and uses Redis with Mandrill to handle the emails. Daniel says that the implementation is not the prettiest, but as a quick way to test out the idea, it works well. If you give it a go, let us know how you get on at @FogCreek.

Introduction to Docker – Tech Talk and Demo

January 23rd, 2015 by Blake Caldwell

 

In this Tech Talk, Blake, a Software Developer here at Fog Creek, gives an introduction to Docker. He covers what Docker is, why you might want to use it, how it works, as well as explaining some key terminology. He finishes up with a few demos demonstrating the functionality of Docker.

 

About Fog Creek Tech Talks

At Fog Creek, we have weekly Tech Talks from our own staff and invited guests. These are short, informal presentations on something of interest to those involved in software development. We try to share these with you whenever we can.

 

Content and Timings

  • What is Docker? (0:00)
  • Basic Terms (3:00)
  • Why Use Docker? (6:45)
  • How Does Docker Work? (10:08)
  • Docker Artifact Server (11:01)
  • Docker Demos (14:45)

 

Transcript

What is Docker?

At its core, Docker is a platform for developing, deploying and running services with Linux containers. So what does that mean? Linux containers – this is a feature of the kernel as of, I believe, 2.6.24 or so, it has been around for a few years. It’s a way of just isolating processes from each other. And you can do a lot of cool things with it.

So one way to look at it is, as chroot on steroids. It’s not just filesystem rooting, it’s also isolating you from all of the other processes of the machine and this is a pretty cool thing when you think about it. Like you can do things like running unsafe code, running lots of stuff on your server without really vetting it, or just running multiple instances of something on the same machine and have them be isolated from each other.

It also seems like when I’m describing it like this, that it’s a VM. That’s usually the first way people think about Docker. ‘Oh it’s a VM, let’s go ahead and set one up. I need SSH, I need to run Apache, I need to run my Python service, lets also install those things on this VM and lets SSH into it’. Well, it’s not a VM. It’s really like I said, it’s a lightweight way of running a process in total isolation. So you can treat it like a VM, but that would be wrong.

Their metaphor and the true metaphor for Docker is that of the problem of shipping along time ago. You have rocking chairs, and you have couches, and you have cars, and you have golf balls… and you have all of these things. How am I going to ship all of these things? You can pile them into a giant pile on a big ship, but that isn’t going to work. I’m sure they started using boxes, then they started using crates and then they realized that all of these crates are different shapes and so they came up with a standard. This standard, there’s these containers that we see passing us on the road all of the time and on these ships, if you get a chance to go to the docks. There’s a standard size for these things, there’s a standard place for where the doors go, for how the locks work, and for where the mount points are to pick it up. So that they all fit on ships and they can get them on and off efficiently and there’s weight restrictions and all this. So that the shipping company doesn’t need to know what’s inside these things, that it hits all of the specs and adheres to all of the standards. And there’s a lot that you can do with that, right. You can watch the orchestration of these containers off trucks and on to ships and you can do some really cool things.

So that’s what Docker is. It takes all your services, your apps, or other people’s apps and it bundles them up in a standard way where you can now have orchestration at the software level. You can deploy these to different machines, you can do all kinds of cool things with this. So that’s the Docker metaphor, it’s containers on container ships.

Basic Terms

So to give you some basic terms, just so we’re clear from the start. A Docker Image is a static filesystem, and in every case except the top level, it’s going to have a parent image. So my basic filesystem might just have like let’s say home directory. So I put home directory in there. It might also have like a user banner, it’s going to hold a whole bunch of binaries, I don’t know. And then I create another image on top of that where I add another layer of the filesystem. And another layer on that, where I am adding this and that and that. And then at some point I’m installing a bunch of services, and every one of these actions are another layer on top. The file system is a copy on write. So if I’m going to overwrite something from a parent image, that’s no problem, it’s just going to overlay on top of that. So, there’s benefits to them being static, which I’m going to get to in a little bit.

An Image is like, you can think of it like, if you installed Debian or something, and you snapshotted it and put it on a DVD, there’s your image. It’s something that can’t be modified at this point. And now when I put that DVD in the machine, and this is kind of a weird metaphor because I don’t want anyone to think of this as a machine, but when you put the DVD in the machine you say you’re going to boot from DVD. Well, now you have the equivalent to Docker as a Container. A Container is a writable instance of an Image. It’s based on an Image, and so in this metaphor, if this holds out we’ll see, as you’re running you’re able to overwrite files that are effectively on the DVD but the time when you’re running it, they’re in memory or in some kind of mount. So when you’re running a Container you can write to any file and again it’s a copy on write, it’s going to be writing its files somewhere. But in another metaphor here, you can think of an image like a Class. It’s a definition, it’s ‘here’s what this thing is’ and then a Container is an instance of that Class. So just like in programming when you can have a hundred different person objects, in Docker you can have a hundred different Containers based on one Image. And that might just be that I want to run bin/bash inside a stock Debian image. Right, so I’m going to run bin/bash inside a Container. And that bash command is going to see a fresh file system that no other instance sees because each has their own instance of that image. And then you can throw away the container but the image always exists in your registry.

And one more point about Containers is that they should be ephemeral. An Image is something that is recorded, it’s archived, it’s shared, it’s deployed to different machines. A Container is just a running service inside this Image and then when you’re done you should be able to delete the Container, there should be nothing special about the Container. And so you start thinking about, you know, in production, you have Logs – I can’t throw away Logs. You have secrets – I can’t throw away secrets. Those things aren’t stored in the container, or in the Image, those things are separate – I’ll get to that later. But start thinking of Images as definitions that are deployed, shared, checked-in somewhere. Containers are just started up and then I should be able to delete the Container. You shouldn’t design Containers in such a way that you’re holding on to them, they’re ephemeral.

Why Use Docker?

So why Docker? It’s a way to ship software in a standard way. And the system requirement is only Linux with a minimum kernel of I think 3.8. And then you install Docker, and that’s all you need. I can create an image of Postgres, of Redis, of Apache, of my own custom software and I can just give it to you as an image, and I say ‘just run this image as a container on your machine, oh and all you need is Docker.’ There’s a whole bunch of cool things you can do with that by running multiple containers at the same time. And it’s not just a deployment tool, there’re benefits at all stages in the lifecycle. In dev, in test, in continuous integration, in integration tests, staging and then obviously in production.

For test and QA, they are able to run multiple versions of your containers, so they can run multiple versions of your app at the same time on the same machine, without worrying about port collisions, without worrying about library collisions. So you can run Python 3 and Python 2.7 at the same time. And I know that you can do that with virtual environments, this is just a way of stepping back and making a standardized virtual environment that works for any kind of script. So you can run a bash script, Python, whatever you want.

Another thing, is that they can run test suites, in parallel without worrying about what else is running on that system because you can set them up in such a way that they don’t interfere with each other.

And one thing that is pretty cool, and I’m not entirely sure if this isn’t an anti-pattern yet after spending more time using it and playing with it. But, if you have your whole system, your whole back-end system in containers you can actually setup, you can setup your system in such a way and snapshot it. And now you have, like say you have a particular customer, that gets into a situation and we want to write some integration test to test what happens when I do this, or do that. You can snapshot, you can archive that and then you can run tests specifically for that state. It’s pretty spooky when you see it work. In production, there’s a lot of cool things you can do. You can limit the resources of a container, limit the memory, the CPU, device access and read/write speed, which is pretty cool.

Also, Docker has a remote API, so you can start querying different boxes and asking what containers do you have on there? And I’ll talk a little bit more about that in a minute.

There’s also since you have a standard format of shipping these things, there’s orchestration tools. And then you have things like where you can add new containers to a resource pool behind an HAProxy server and dynamically scale up and scale down if you set up the dynamic container discovery.

How Does Docker Work?

So how does this work? I mentioned briefly that it’s using the LXC, Linux container technology. That laid the groundwork, apparently working with LXC is kind of cumbersome. Docker decided to put a nice abstraction over that and make the thing easier to work with. So I mentioned that you have file system and process isolation and I mentioned also that this isn’t a VM. But what’s nice is, when you start playing with this, at first you’re thinking there’s an overhead here, right? Well, there’s not as much overhead as you might think and in many cases it’s almost zero. All Docker is doing is orchestrating, it’s saying ‘hey Kernel, I’m going to run this process, I want you to run this process in isolation and here’s the filesystem you’re going to use,’ and then Docker steps away. Processes are still running in the host system’s Kernel, which is great because then there’s very little latency to access memory and very little CPU overhead. And no Hypervisor.

Docker Artifact Server

And now I have all of these images running everywhere, so what do I do with them? Let’s say that we have a developer on our team building these images and we plan on using them in staging, prod, test, dev, all of these places. So what do we do with them? How do I give you my image?

Well, you push them to a thing called the Docker Registry. Registry is a terrible work, it conjures up images of the Windows Registry. So I’m calling it the Docker Artifact Server. It’s just a web server that you can run and push versioned images to. So what does that mean? I can download the Debian images, which is a series of layers, but in the end I don’t care. I just see the layer stack. I can build on top of that and I can call this fogcreek.com/blake-docker-demo and then I can push that with a version 1.0, I can push that into our own copy of the artifact server. Now I can make a change an push in 1.1, same thing. So the Docker Registry is Open Source, and they have a public hosted version of this, called the Docker Hub. And basically, anyone who wants you to use their software on a server is creating an image, you can create any image, and post it on there and publish it for free. If you want to do private images you can pay them some money, it’s the same business model as GitHub. So public is free, you can push your own private repos in there. Here’s an example of what you see on their main page. So if you went there now and said ‘I want to download pre-made Docker images,’ Redis, ubuntu, MySQL, they’re all just sitting there. There’re thousands, anything you want is in there. If you want to prototype something real quick, and you know you’re going to need a Redis server, a MySQL, WordPress, whatever, you can put together a series of images that are talking to each other as containers. And they come with documentation, so you can be up and running with a Redis server is minutes. You’re not installing Redis on your machine, which is awesome. You’re just spinning up an instance of Redis. Say you don’t like the version, you can roll back to a version. You can have multiple versions on your system all running at the same time. For any of these things. This is a standard way to install whatever you need.

Now pushing makes sense right, this is easy to understand. During development, I’m going to make my version of my Python app, I’m going to box it up in a container, image it, check in the definition of the image, which is called a Docker file, and then I’m going to push this to our Artifact server. And after I tell the testers, and hopefully I’ll have an automated system that’s running all of the tests on these. Once I’ve got their blessing, all that means is production would then just say ‘oh, I need to start up these five containers from these images, I need Blake’s Docker Demo v1.1, I need the official MySQL 1.2, whatever and it’ll go out on to the Internet and go on to the Docker Registry and just pull down those images for you. So it’s a nice way of pushing stuff to different environments and having the exact same build.

It’s easy to get carried away with this. I’m still trying to figure out best practices, but you can definitely go too far with this. There’s some guidelines that I’ve read, like ‘would you want 50 instances of this running on this machine’, If the answer is ‘hell no’ then you probably shouldn’t be Docker containerizing this. So somethings are better off not in containers. It may be your database server, that is always going to be on one machine, maybe it is Redis. I don’t know exactly, but I think when you have a new tech like this you have to be careful that you don’t overdo it.

Docker Demos

Demo Time!

Lessons Learned from Building Liberio – Interview with Cat Noone

January 21st, 2015 by Gareth Wilson

Looking for audio only? Listen on

 

In this interview with Cat Noone, Chief Design Officer at Liberio, we discuss the lessons learned from building Liberio. We cover how they set out to build an MVP that didn’t compromise on User Experience, the usefulness of their private beta and how to keep focussed even when running side projects. We finish with hearing about resources for non-designers interested in product design.

You can learn more about design, startups and tech on her blog.

 

Content and Timings

  • Introduction (0:00)
  • About Cat (0:24)
  • What is Liberio? (0:40)
  • Building a Quality MVP (1:44)
  • Running a Private Beta (3:16)
  • Having Side Projects (7:45)
  • Recommended Product Design Resources (8:38)

 

Transcript

Introduction

Derrick:
Today we have Cat Noone, Co-Founder and Chief Design Officer of Liberio. Mentor and creator of plenty of side-projects including DesignerRelationships, Coo and Typoguide. She speaks at conferences and writes about design, startups and tech on her blog at heyimcat.com.

Cat, thank you so much for joining us today. Why don’t you say a bit about yourself?

About Cat

Cat:
I’m a designer, I’m actually Chief Design Officer for Liberio. Yeah, I like to blog a lot about startups and design and tech and all that fun stuff.

What is Liberio?

Derrick:
So I kind of wanted to ask you a bit about Liberio. What is it? Where did the idea come from?

Cat:
So in a nutshell, Liberio is a platform for eBook creation and publishing. We originally started off with you being able to do it right from Google Drive, and then we expanded to OneDrive, DropBox and GitHub and of course, Google Drive.

The idea actually came from my partner, who is the CEO of Liberio. He actually grew up in a publishing family. His family ran a publishing house and so he had this first hand experience of this traditional perspective of publishing and as a result saw what was needed for self-publishers to actually start a career and have a successful career in self-publishing. And previous to that the process to actually create an eBook and actually publish it was extremely convoluted. So, we simplified it.

Building a quality MVP

Derrick:
You’ve blogged before about MVP quality, and the importance of not skipping over User Experience from the outset. How did you approach building Liberio with that in mind?

Cat:
Well, so I think the biggest thing is that User Experience isn’t something to be skipped over. It’s not like this one part of the entire process in the produce that you tackle, kind of like visuals. User Experience is the entire thing. It’s your visuals, it’s your copy, it’s everything. So for us, from the beginning we said that we wanted to create something that people can relate to, that feels personal, clear copy, super simple, easy to use for the average person. We didn’t want it to be something that only people in tech could understand. You know, or people that were tech-savvy like designers or engineers. We wanted students using our platform, and teachers, and the average Mom. Whoever, it doesn’t matter. So we went into it with that in mind. Making it as simple as possible, clear and concise copy, you know, nothing that is confusing. And of course the last bit is beautiful visuals, or as beautiful as possible. And nothing is perfect, it’s not close to being perfect and it probably never will be, but we’re working towards it.

Running a Private Beta

Derrick:
So you have a Private Beta, how useful was it and how did it influence your product?

Cat:
Super useful. It gave us so much more insight than we would have received than if we had just launched and thrown it out there. We took six months to look at what everyone on the platform was doing and made a point to reach out. Whether it was just emails from us as a whole, or personal emails that we sent out to just say ‘hey, what are you having trouble with? We will help you. What do you want? More importantly, what do you need? And that’s what we got out of the private beta, was what exactly was needed as a self-publishing author, and where do the troubles, the error and the frustrations typically lie when it comes to this entire process? So for us, it was beyond useful.

Derrick:
So up until then, how did you know when the product was ready for launch?

Cat:
I think once the platform really started growing. The numbers were increasing daily, and weekly and monthly. Feedback was increasing, the amount of eBooks being created and published. Every single thing we could measure was increasing, and the complaints of the entire process started turning in to feedback, positive feedback for what we were providing. And at that point we said ‘ok, lets get it out there, we have as much feedback as we think we’re going to have in a private beta, lets push it out, and of course even after we’re going to push it out we’re going to iterate on the product, so lets do it’ and we pulled the trigger.

Derrick:
What was that launch like for you?

Cat:
It was nerve-wracking and it was exciting. I think at that point for us we were just super-excited for everyone else to see it. You know, for me personally, sitting behind a screen and designing it and talking to everyone. It was like this big secret that everyone knew I was working on but didn’t have a chance to see it. And I knew that there were so many more self-publishers that would find it useful. Not only self-publishers but students and teachers, you know Liberio is big in the class room, so we really wanted to push that out. After that, after we did, yeah it was big, it was exciting, it’s doing pretty well, can’t complain. So I guess it was pretty successful. I mean it has changed a lot since, there’s a lot being worked on. We’ve received a ton of feedback after launching, that we didn’t receive in private beta, so I think it was the best decision.

Derrick:
How did you start getting that feedback from people after the launch?

Cat:
So I think when we were in private beta, we of course made a point to reach out to the people. But after launching to the public, a lot more people were willing to actually share that feedback. Of course bugs popped up, things broke, so we heard from people of course when things go wrong. But a lot of people actually reached out and said ‘hey, you know, I love this, this is one of my favourite things, I would also like to see this, I also need this, I also just want this.’ So we took the wants and the needs, we separated them and used them to prioritize and used that to validate what we already have on our road map. And we’ve been going from there since.

Derrick:
Was there anything else that, sort of, helped you keep focussed on the original problem that you were set to solve?

Cat:
Just the fact that we know that that’s something that we’re solving but there’s this funnel to self-publishing and we’re trying to solve the eBook creation and publishing, but we know that there’s more that comes with self-publishing. So now we’re trying to work on that, while continuing to work on trying to make the product as simple as possible. Always looking for ways to make it as easy as possible to create and make a beautiful eBook. There’s still these sub-sections to the platform that can be improved and that’s really what we’re focussing on.

Having Side Projects

Derrick:
You’ve got a number of side-projects going on, how do you find the time to work on these and how do you think they help you?

Cat:
So obviously working on Liberio takes up the majority of my time. And so the side projects happen, you know, late in the evenings or on the weekends when I have the spare time to actually sit down in front of a computer, or have the want to sit in front of a screen. But yeah, for me, they are not a priority but are something I do for fun and to better myself as a designer, as a product person. Learn, grow, so I mean for me it’s not something that I do every single day, I think for me that would totally burn me out because at that point is becomes a big project, not a side project.

Recommended Product Design Resources

Derrick:
What are some resources you can recommend for people that want to learn more about product design?

Cat:
I think for me, obviously I do a lot of reading, and I pay a lot of attention to Twitter. That’s where most of the content that I read comes from. And I’m really, really picky about who I follow. And I like following people who share insights and who can help me grow as a person and as a designer. So I think, yeah, really pay attention to who you follow, follow people who share some really insightful stuff, oh and read. Do you best to read, learn and above all, more so than reading, just do it. You have to do it, practice, throw something together and I think you’ll be golden from there.

Derrick:
Cat, thank you so much for joining us, taking the time out of your day, I really appreciate it.

Cat:
Thanks for having me.

7 Tips for Better Developer-Designer Relations

January 20th, 2015 by Gareth Wilson

Typical organizational groupings mean that designers and developers often find themselves in separate teams. Also, a common perception of the people in these roles are that they are different – developers are logical, analytical, left-brainers whilst designers are the creative, flexible, right-brainers. And whenever people are separated like this, it’s easy for the relationship to become adversarial. Pretty soon all you do is focus on the differences. They become those hippy-dippy designers with their strange and impossible requests. Or those vision-less, code monkeys. A ‘Us vs. Them’ mindset takes hold, leading to a break-down in communication, which gets borne out in poorer products.

83 (1)
But does it need to be like this? I mean, there’s a lot of common ground. Both have a keen eye for detail, solve problems in creative ways and often share a love of great tools and technology. What’s more, the theory around what you can do to overcome these issues is simple. You just improve communication, empathize with the other team, respect their contributions and build trust. Yet, actually achieving that can be tricky.

So, here’s seven practical things you can do to help designers and developers work better together:

1. Mind the Pet-Peeves

Developers:

  • Be Clear About What You Want

    Often it seems that designers are expected to be mind readers. The brief for designers can be little more than “go make this look good.” Just as a developer might ask for a requirements specification, a clear brief for a designer is also important. Be sure to provide examples of what you mean. These might just be links to how others have approached a similar thing or even a quick sketch.

  • Be Mindful of Design Constraints

    If you’re working with data, then supply real samples if possible. Knowing the data ranges you’re trapping in your code can be useful for designers to know too. Designers also need to know things like screen sizes and browser compatibility from the start.

  • Be Open About What’s Achievable

    Developers can be the gatekeepers of what gets implemented. A big idea can all too often be dismissed out of hand in the name of time or performance constraints. Often though there’s a compromise to be made, with some part of the original idea being possible. So staying open-minded and working with the designer to find that compromise is important.

    Designers:

  • Make Your Assets Easy to Work With

    Name different file versions so that the latest version or the one you want to be used is easily found. Maintain the layers in image assets, naming them usefully and grouping them whenever you can. Don’t forget to also remove any old and no longer needed layers and files. If possible, prepare the assets for use too – cut them up so that they can be used straight away.

  • List Out Key Details

    List out the names of fonts, text sizes and hex color codes used, along with the widths, heights, padding and margins you’re expecting. Doing this can be a real time-saver for developers.

With those pet peeves eradicated, you can start to focus on processes and ways of working.

2. Work Closely Together

This can be just having designers and developers sit next to or near each other. This helps encourage short, informal conversations that lead to more open and frequent communication. But this can also be applied remotely too with regular video chats and Instant Messenger or Group Chat. Either way, if you do this, then over time you’ll absorb knowledge about each others work.

3. Start Communication Early, Continue Regularly

64 (1) (1)
It’s best to start communication between the two teams as soon as possible into a project. If you build it into your process right from ideation, then there are no surprises that can cause problems later. So start off with designers and developers working together on how they can approach the project. Then continue the communication right throughout the build too. Look for opportunities to keep each other up to date on progress and developments. So, for example, when working on wireframes, designers can involve developers in deciding how to work with different screen sizes, devices, and browsers. Designers can share sketches, and likewise, developers can share links to works in progress. At all stages, bounce ideas off of each other, not just your own team, and break out onto white boards when you need to work through a problem.

4. Pair Designers and Developers

When the chance to work together doesn’t emerge itself, you should actively encourage it with designer-developer pairing. For example, as Cap Watkins recommended in our recent interview, designers and developers can work together on a design bug rotation. This is where designers and developers pair up to work through a list of design issues. This involves discussing the problems, deciding on solutions and fixing them together. By doing this, designers are given insight to the code and developers are exposed to design-related issues.

5. Open Up Design Critiques

Opening up design critiques to others is a great way of helping them to better understand design work. This is something we’ve started doing at Fog Creek. We’ve seen that by showing example work and then walking through the design rationale, non-designers can better appreciate design issues. What’s more, describing how you’ve considered implementation issues shows that you’re taking developer problems seriously.

6. Run Designer and Developer Placements

For example, Etsy runs an engineering placement program. This program aims to get employees with no technical knowledge to deploying simple code changes in a few hours. Spending time working with other teams, even for a short time, helps to foster cross-team communication. This can be taken further too, with embedded team members, so designers embedded in development teams and vice-versa. Trish Khoo explained how this works with embedded test specialists at Google, in an interview with us.

7. Learn about Design or Development

Knowing even a little about code will make you a better designer. It’ll help you to understand and resolve implementation issues that you would otherwise have run into later. Similarly, some understanding of the theory and processes involved in design work will enable you provide more useful feedback. Learning about design does not mean you have to be creating design assets. And the same goes for code too. But by at least knowing the terminology and key concepts, you’ll be able to have more meaningful conversations about design and code issues.

By thinking through and creating opportunities for designers and developers to work on issues together, you can encourage a closer and better working relationship.

Ending Your Remote Meetings with Style & Panache

January 14th, 2015 by Rich Armstrong

New media take a while to develop their own conventions. Alexander Graham Bell suggested “Ahoy” as the standard telephone greeting before English speakers settled on “Hello.”

As Fog Creek has gone from a single location to a worldwide remote team, we’ve shifted our meetings mostly to Google Hangout. If you do a lot of these meetings, you might notice that it’s often awkward to end them. There’s the “ok, that’s it,” then, “bye, talk to you later”, followed by fumbling for the close button and hoping nobody had just one more thing to add.

Nobody walks away feeling awesome.

Well, forget all that. Here’s how the FogBugz team ends their stand-ups:

Features: unanimous agreement that the meeting is over, a point after which additional talking is moot, plus the bonus of getting to feel for one moment like a Power Ranger.

Designers Doing Development – Interview with Cap Watkins

January 14th, 2015 by Gareth Wilson

Looking for audio only? Listen on

 

In this interview with Cap Watkins, the new VP of Design at Buzzfeed, formerly Sr. Design Manager at Etsy, we discuss his approach to product design and design management. We cover how to get and use feedback, why designers should code and engineers should design as well as working practices to encourage this. We finish with hearing about resources for non-designers interested in product design.

You can learn more about design and design management on his blog.

 

Content and Timings

  • Introduction (0:00)
  • About Cap (0:24)
  • Competitor Analysis (1:34)
  • Getting and Using Feedback (3:10)
  • Why Designers Should Code (6:30)
  • Why Engineers Should Design (10:20)
  • Recommended Product Design Resources for Non-designers (12:38)

 

Transcript

Introduction

Derrick:
Today we have Cap Watkins, VP of Design at Buzzfeed, previously Senior Product Design Manager at Etsy, previously in design roles also at Amazon, Formspring and the first designer at Zoosk. He speaks and writes about design and design management topics at conferences on his blog at blog.capwatkins.com.

About Cap

Cap:
So I like to start with a confession before I talk about design stuff. I’m not a designer. Sorry, I’m dropping this on you right now, but I’m not a design by education or anything. I was actually a Creative Writing major in College and got out of College and didn’t really, like every good English major, I didn’t know what to do with my life. And went and did what every good English major does and worked in a coffee shop for about a year. Wrote a bunch, played on the Internet. I had learned pretty early, when I was sixteen how to write HTML and use Photoshop 4.0 at an internship I had. So I was doing that for some friends for like cash on the side. A couple of friends got their startup funded in Oakland and needed a cheap designer, which was me because I figured it was better than my coffee shop job. And so I moved out to Oakland and, yeah just went from there, that was my first startup. And then went on to work at Zoosk, like you said, Formspring, Amazon, Etsy.

Competitor Analysis

Derrick:
You’ve written a few posts about your design process and one thing I noticed right away was that Competitor Analysis was right there with the problem definition at the beginning, why is that such an important stage?

Cap:
It’s hard to, I think some people feel weird about that, some people feel like concerned that they will see something that someone else did and they’re not going to be able to think outside of it. I know that some designers try and silo themselves away from competitor analysis, at least at like, the beginning. I’ve found it super useful, I think like whenever I do design work, I’m always writing down the pros and cons of each approach that I’m coming up with, because nothing’s perfect obviously. It’s good to be honest with ourselves about what is good and bad about what we have done. But what’s really helpful to me is looking at what other people have done, and the pros and cons of those designs, so that I can avoid the cons of the designs and take some of the things that I really like.

When we’re working on Etsy, we’ll look at Ebay, we’ll look at Square, Shopify, which are all great products but obviously different from Etsy and have different problems they are trying to solve. So the pros and cons of those, what’s good and not so good about those designs, helps us identify opportunities that we’re missing, or problems that we want to avoid. I’d rather know that upfront, not get like 6 weeks down the road and see this other thing and be like ‘oh, that’s pretty good’ or ‘yeah, that’s bad and I’m doing that too.’

Getting and Using Feedback

Derrick:
So, you’re looking at other products in similar spaces and getting feedback. There’s other ways about getting and using feedback that’s heavily build in to your process too. What are some of the techniques and tools that you use to get feedback on your work?

Cap:
Sure, so at Etsy what we use is Basecamp. It’s like a religion for the design team. We use it kind of differently than I think that other people do. Basecamp is actually Project Management software, but we don’t use it that way. It’s just for design work at the moment. So what happens is, there’s 27 product designers at Etsy now, and it’s really hard to keep up with everything going on obviously for all of them. And we are all better off if we’re seeing each others work all of the time and able to give feedback. And also just see what is happening. So when I’m like designing something and someone else is, we can like merge those efforts if we see the opportunity. And so what Basecamp does is it allows us all to, we put all of the designers on every project, so every designers adds all of the designers to their project and then starts posting work. Constantly, right the way throughout the process. Every project starts off with a written list of problems we’re trying to solve, goals and that sort of thing. And then it just goes from there. So it’s like a constant, regular feedback loop. And then the other thing we do, we have a couple of in-person meetings each week. So like, a small design team will get together each week and the larger design team will get together once a week to share, get feedback and critique. Obviously with 27 designers, the bigger group thing is little bit more high-level. It’s hard to get like deep down in the weeds with it, but like, it works pretty well.

Derrick:
You’re obviously working on things that are visual, it seems like everyone is going to have an opinion, with a lot of feedback like that going around. How do you know what to listen to?

Cap:
It’s a good question, it’s something that we’ve been working on at Etsy. Because also, in addition to the designers, your entire team of engineers and product managers are on those threads as well. So like a designer will put their product manager and engineers on the thread with all of the designers. And we kind of figured out, it was OK for a while, we only had 9 designers for a while, and it was OK because we were only small and we had pretty tight feedback, so it was OK. Now there’s a lot feedback at times and it feels somewhat overwhelming. So what we’ve been trying to do is, we kind of made a blanket statement, so if it’s your team responding, so if it’s your engineers, your PM, your design manager, the other designers on your team, then that stuff is important to listen to. So like make sure that you respond to, make sure you’re having that conversation that’s open. But if it’s coming from outside of that team, like another design manager outside of your team, then it’s just an opinion, you do not have to, there’s no actionable thing to do there. Unless you think that you should. Like that’s a good idea, I should do that. We’ve also set that expectation with everyone else. So if you’re outside the team, give feedback, no problem, say whatever you want to say, do not expect, like there should be no expectation of action. And if you feel super strongly about it, like come talk to the whole team, and have that conversation, but don’t like you know, fire off like a one-off opinion in to Basecamp or in to email or something like that. It’s a randomising thing.

Why Designers Should Code

Derrick:
Any key part [of your design process] is coding up your designs. Why do you think designers should code?

Cap:
For the same reason I think engineers should design. I think, I’ve never not coded. Just like, I’ve been in startups for so long where being a designer also meant I wrote the front-end for everything I did. And it made working with my engineering partners like, really, really easy. Because we were talking about the same thing, which was the codebase. And I could like, I don’t know how to write back-end architecture or anything like that, but because I am talking to them about the front-end architecture they are explaining to me the harder, the more complex parts of it, of what they do. So because I’ve worked with them so closely, I have this mental model of how things work so we can have an intelligent conversation about back-end architecture sometimes, without exactly knowing what I am talking about. And I just feel like that cross-pollination of responsibilities and ideas, like makes the product that you are working on better. Because everybody is responsible for everything. Designers at Etsy are also like semi-product managers. They think about the product we are working on, where we’re going, why we’re going there, like how to get there, what’s next. And like the engineers think about that stuff too, we have a lot of great product-minded engineers that really care about those same questions.

I’ve been at places where it has been siloed and it hasn’t been that great. And the product is not as good as it could have been as if people had shared the responsibility. And like, front-end, HTML and CSS, isn’t that hard to learn. Like, it just isn’t, it’s very presentational. Like, some of the more complex stuff gets harder, but just dipping your toes in is pretty simple.

And we have a lot of mechanisms at Etsy to teach those how to do that. We’ve hired designers who are strong at UX and Visual Design but aren’t quite there with front-end stuff. And like, we have a strong engineering team who will totally help teach the designers how to write code. We have a design bug rotation once a week, where two designers sit down and crush through a bunch of design bugs on the site and deploy them. And we’ll pair people together, so someone super senior in that area and then maybe someone who is just coming along. They’ll pair with them and be able to help them. So there’s a lot of mechanisms for providing that. And I think it’s because the whole organisation buys in to it that we’re able to do that. If the engineers were like ‘we don’t want people in our code, period’ then it would be a lot harder, right. But luckily they’re all like ‘this is amazing, I can’t believe this happens, this is good.

Cons are definitely you’re limiting yourselves to who you can hire. I talk to a lot of designers who are great designers, don’t write the front-end and have zero interest in doing that. So we hire people sometimes who haven’t written HTML and CSS hardly ever. But it’s all circumstantial though right. There in a place that doesn’t let them do that, or like they’ve just never had the opportunity but they really want to, and we’re totally down for that. No problem, come on let’s go. Yeah, so I definitely talk to a lot of designers who don’t want to do that, ‘it’s not my job’. Which is totally a legitimate and reasonable thing to say, it’s just not something that fits in with our culture at Etsy. And it makes it hard, there’s just not that many people who are good at everything like that. At like the whole stack of design, so that’s tough. I talk to a lot of designers, to find like, the ones that can do this stuff.

Why Engineers Should Design

Derrick:
You said developers should learn design too, is that something you strongly believe in?

Cap:
Yeah, like I just want everybody to feel as close to the product that we’re building as possible. I want everybody to feel like so much responsibility, from the very, very first meeting all the way through to like deploying the code at the end. So we involve engineers in all the design discussion that we have. So we’ll have a design kick-off at the beginning where we’ll just like run through problems, like ideas, like we’ll be sketching together. I constantly see people going to whiteboards together and working through design problems with an engineer and with a PM obviously. And it’s like, engineers don’t have to create the artefact. If you think about design as just a thing you make, like it’s the photoshop file, or it’s the sketch file, it’s like, yeah probably not. Engineers are probably not going to do that, they shouldn’t have to do that. But if you look at it like more of the process of product development as one continuous timeline it all starts to make more sense. So yeah, if you just like siloed off, if you have a timeline that’s like this long. Oh we design this much, and we engineer this much, and then we deploy and measure this much. Like, siloing those things off feels like, bad. When it is one timeline, if you look and everyone’s involved from here to here, then it means that you like won’t drop as much stuff. People will feel like at the end that they can really defend what we did, and are really invested.

Derrick:
Are there any other practices that you use to encourage coding skills in designers, and vice versa, design skills in engineers?

Cap:
We just got finished sending a lot of engineers to essentially bootcamp for iOS and Android development. And it was funny, as soon as the design team found out we were doing that I got like ten emails that were like ‘I want to go to that.’ So we sent a bunch of designers, I think all of them actually signed up to go to these bootcamps to learn Objective C and Java. Which is completely outside of what we expect from them, but like they just can’t help themselves. They just really want to get in there.

Recommended Product Design Resources for Non-designers

Derrick:
Do you have any recommendations for non-designers interested in developing their knowledge and understanding of product design?

Cap:
Designer News is like a pretty cool resource, just to like see what’s going on. Like, a lot of designers do this – just ripping off people until you get it. Until they understand why something is happening. And a lot of the advice I give to folks is like, just to go design stuff. Build stuff. As for critique from a designer you know.

There’s an engineer at Etsy who is like always building a side project. Always. Like never doesn’t have a side project. And it’s always super cool and he’s always sending me his projects and is like ‘so what do you think to this design?’ And like he bought himself Sketch. Sketch is like 50 bucks or something like that on the App Store and pretty easy to get. Pretty cheap to get. And started fooling around with tons of tutorials online. And you can just like find a designer, a designer you like who will spend time with you. I find engineers I like to spend time with me and stuff.

Derrick:
Great, fantastic. You’ve given us a lot to think about today, I really appreciate your time today Cap. Thanks for joining us.

Cap:
Thanks for having me.

Derrick:
No problem.

Stop More Bugs with our Code Review Checklist

January 8th, 2015 by Gareth Wilson

In our blog about effective code reviews, we recommended the use of a checklist. Checklists are a great tool in code reviews – they ensure that reviews are consistently performed throughout your team. They’re also a handy way to ensure that common issues are identified and resolved.
100_blue (1)
Research by the Software Engineering Institute suggests that programmers make 15-20 common mistakes. So by adding such mistakes to a checklist, you can make sure that you spot them whenever they occur and help drive them out over time.

To get you started with a checklist, here’s a list of typical items:

Code Review Checklist

General

  • Does the code work? Does it perform its intended function, the logic is correct etc.
  • Is all the code easily understood?
  • Does it conform to your agreed coding conventions? These will usually cover location of braces, variable and function names, line length, indentations, formatting, and comments.
  • Is there any redundant or duplicate code?
  • Is the code as modular as possible?
  • Can any global variables be replaced?
  • Is there any commented out code?
  • Do loops have a set length and correct termination conditions?
  • Can any of the code be replaced with library functions?
  • Can any logging or debugging code be removed?

Security

  • Are all data inputs checked (for the correct type, length, format, and range) and encoded?
  • Where third-party utilities are used, are returning errors being caught?
  • Are output values checked and encoded?
  • Are invalid parameter values handled?

Documentation

    integration testing

  • Do comments exist and describe the intent of the code?
  • Are all functions commented?
  • Is any unusual behavior or edge-case handling described?
  • Is the use and function of third-party libraries documented?
  • Are data structures and units of measurement explained?
  • Is there any incomplete code? If so, should it be removed or flagged with a suitable marker like ‘TODO’?

Testing

  • Is the code testable? i.e. don’t add too many or hide dependencies, unable to initialize objects, test frameworks can use methods etc.
  • Do tests exist and are they comprehensive? i.e. has at least your agreed on code coverage.
  • Do unit tests actually test that the code is performing the intended functionality?
  • Are arrays checked for ‘out-of-bound’ errors?
  • Could any test code be replaced with the use of an existing API?

You’ll also want to add to this checklist any language-specific issues that can cause problems.

The checklist is deliberately not exhaustive of all issues that can arise. You don’t want a checklist, which is so long no-one ever uses it. It’s better to just cover the common issues.

Optimize Your Checklist

Using the checklist as a starting point, you should optimize it for your specific use-case. A great way to do this is to get your team to note the issues that arise during code reviews for a short time. With this data, you’ll be able to identify your team’s common mistakes, which you can then build into a custom checklist. Be sure to remove any items that don’t come up (you may wish to keep rarely occurring, yet critical items such as security related issues).

Get Buy-in and Keep It Up To Date

As a general rule, any items on the checklist should be specific and, if possible, something you can make a binary decision about. This helps to avoid inconsistency in judgments. It is also a good idea to share the list with your team and get their agreement on its content. Make sure to review the checklist periodically too, to check that each item is still relevant.

Armed with a great checklist, you can raise the number of defects you detect during code reviews. This will help you to drive up coding standards and avoid inconsistent code review quality.

To learn more about code reviews at Fog Creek, check out the following video:

Using Empathy to Create Products People Love – Interview with Jon Kolko

January 7th, 2015 by Gareth Wilson

 

In this interview with Jon Kolko, author of ‘Well Designed: How to Use Empathy to Create Products People Love’, we discuss his design-focussed product development process. We cover how to get and use feedback, how to know what feedback to focus on, the importance of building products with personality and how non-designers can learn more about product design.

 

Content and Timings

  • Introduction (0:00)
  • About Jon (0:27)
  • Why Emotional Engagement of Users is Important in Product Design (0:50)
  • Product-Market Fit (3:15)
  • Getting and Using Feedback (5:20)
  • Building Products with Personality (9:12)
  • Applying the Techniques to Existing Products (12:18)
  • Recommended Product Design Resources for Non-designers (13:20)

 

Transcript

Introduction

Derrick:
Today we have Jon Kolko, VP of Consumer Design at Blackboard and Founder and Director of Austin Center for Design. Previously Creative Director at Frog Design, Professor of Design at Savannah College and has recently published his fourth book with Harvard Business Review Press entitled ‘Well Designed: How to Use Empathy to Create Products People Love’. Jon thank you for joining us today, why don’t you say a bit about yourself.

About Jon

Jon:
How are you? Thanks for having me. That was a pretty robust introduction so I’m not sure there’s anything left to say, except I’m happy to be here. I enjoyed writing the book, I’m hoping that it’s a well received tool for people in design roles that are getting in to product and really drive a more strategic focus in their organizations.

Why Emotional Engagement of Users is Important in Product Design

Derrick:
It describes a design-focussed product development process that really focusses on the emotional engagement of users. Why is that important?

Jon:
It’s a good question, you know, traditionally products have been driven by technical requirements, technologists getting excited about what the product can do or you know, marketers really sort of trying to amp up the competitive landscape. Trying to 1 up people on features and functions. Sorry of my go to example there is like the Mach 3 razor, and just adding another blade over and over. And may be that was a good idea, may be it wasn’t a good idea but it certainly doesn’t seem to work with digital products. I think for a couple of reasons.

First, the complexity of the products. And sort of the ability and interest of people to use them and understand those things. And the second is the intimate way that we bring these in to our lives. If you think a little bit about most of the products we use and love, like Facebook, or Twitter, Pinterest or whatever they are. They’re not just utilities any more, they actually describe and get at our identity. And so, I think we need a different process to drive those and at the heart of that is the people who are going to use them. The technology and business interests become secondary, and the people and their emotional needs become the primary.

Derrick:
Eventually you want people to feel good about what they are using.

Jon:
Yeah absolutely, and I don’t think that good is even the right word. It’s certainly part of it, you don’t want people to feel bad. But I think really it’s about creating engagement. And I don’t necessarily mean a SEO marketing sense, I mean a much more resonate sense. If you think about the stuff that you bring in to your house. Sort if your house was on fire what do you take. You know and you can only carry one thing. When you get past the people and the cat, most people get to pretty intimate stuff like old photos or maybe pieces of art or things that have personal meaning and stories embedded in them. And that’s really the level of engagement that I think we’re trying to drive in to product design now. Which means that good is sort of like table stakes, of course it has to be good, but it actually has to be emotionally moving. And that doesn’t necessarily mean that we need to shed a tear over using Pinterest or something like that, but I think that there’s this level of wanting to drive love. Love the products that you are using. And again, I think that requires a different way of thinking about product development.

When you get out of the building what you do matters

Product-Market Fit

Derrick:
Part of the process is knowing the people, but also determining the market-product fit. What is the product-market fit and how do you know when you’ve reached it?

Jon:
Yeah, it’s a good question. It’s sort of thrown around a lot in hip startup land, in lean startup land. I think about it, first I’ll give an example. And it’s an example that I like to use a lot because I think it is crazy. Think about Google Glass and sort of how bizarre it is, right. It’s not just technically advanced, it’s like normatively advanced. We’re not ready for it as a culture, so when we see people using it, it feels really strange. Right, it feels disconcerting for non-technologists when they encounter somebody with it. It’s a curiosity piece but it’s also just bizarre. And I think it’s because there’s very little precedent for wearing computers on their face. But if you sort of tap back off a little bit, we actually do have a precedent for that in Bluetooth headsets. And years ago we didn’t see people wearing those things. And the first couple of times we saw people talking to themselves on the Subway or whatever, wow that’s strange. But now, I wouldn’t say it’s un-strange, but it’s less strange. So we’re starting to see cultural adoption of these things. And when I think about Product-Market fit, that’s one of the key components of it. Is culture as a whole ready for the innovation that you’re driving. Because technology is strange and design’s role is to make it familiar and humanise it. And so if you think about any of the innovations that we’re tracking, Uber, AirBnB, the technology is actually fairly simplistic in what makes those work. It’s actually the cultural norms that are changing. Like are you actually ready for someone to stay in your house when you’re not there? And I’ll give you a quick anecdote.

My parents came for Thanksgiving and my sister did as well. And my sister was all excited to get an AirBnB and experience Austin sort of traditionally. My parents said ‘no way! we’re staying at the Days Inn’ or whatever it is because it’s predictable. They understand what the experience is going to be like. And so, that’s starting to become a cultural norm, but it’s not there for my parents, they’re late adopters.

A lot of Entrepreneurs that I meet, they’re really void of opinion.

Getting and Using Feedback

Derrick:
How do you start to really get feedback from people as a key part of your process?

Jon:
Yeah, I think that may be the most important part. It’s the idea of ethnographic research to drive product innovation. I think that most product development processes, like Lean, and things like that, recommend that you get out of the building. And I couldn’t agree more, except the difference is that when you get out of the building what you do matters. You could ask people a lot of questions, you could have questionnaire and ask them ‘would you buy this?’, ‘could you see yourself in this?’ or you can watch behavior. And that’s really the secret sauce behind how all of this really works. When you watch people you get to insights, you get to fundamentals about human behavior. And I consider these sort of provocative statements of truth. You can craft these fundamentals about the way things are and then you come back in to ways think should be. And I can sort of give you a quick example of how that plays out in my world.

I joined Blackboard as, through an acquisition of MyEDU, which was a startup. And MyEDU focussed on succeeding in College and getting a job. And we did a lot of this qualitative research that I talked about. We spent tons of time with college students, in their dorm rooms, watching them plan their schedules, using the different tools that supported them. And we identified a bunch of utilitarian issues, like improve usability of this and increase the functionality of that, but really we noticed an underlying theme of anxiety. College students are really sort of worried about all the steps in the process and if you think about it there’s a pretty rational reason why. Each step is positioned as critical for the rest of your life. You know, you pick a school and it effects the rest of your life. Pick a major and it’s the rest of your life. And obviously that’s not true, if you reflect on your own experience and I feel most of us as we get older know that’s not how it played out. But this level of anxiety is really under all of these decisions. So how that plays out in our products, is instead of saying we’re going to offer all of the capabilities, we say we’re going to offer this emotional proposition – everything we do is going to minimize anxiety. And if that becomes the criterion, then we can start to assess the capabilities to include based on that, rather than a set of requirements.

Derrick:
A quote often associated with Henry Ford is ‘if I had asked people what they had wanted, they would have said faster horses’, how do you know what feedback to listen to?

Jon:
Yeah it’s really a great quote. It does sort of capture the essence of this stuff. I’ve often wondered if he really said that or if that’s legend. But anyway, I think the essence is right, and it’s actually up to the designers and the product managers. It’s not just about just doing what the customers says, and I actually think that’s a big trap that you can get in to with some of these Lean approaches. Is if you leave the building and ask customers what they want and then build it, and it doesn’t work. It’s actually about interpreting the data. And what that means is having an opinion. If you think about some of the products that we love, and delve in to some of the product managers that work on those, which I do in that book, there’s a number of interviews, they have an opinion, right. They have a North Star that they’re planning for. The qualitative research informs the emotional story around the opinion and it informs the execution of the opinion. But it’s not a blank slate, right. You’re not simply chasing whatever the next thing is. And when I reflect on a lot of Entrepreneurs that I meet, they’re really void of opinion, they just want to make a zillion dollars. And I’m a fan of making a zillion dollars too but I think that you have to start with having a firm sort of view of the world, like how the world should be, how it’s broken now and using that to actually drive a lot of the research.

Building Products with Personality

Derrick:
Thinking around products often focuses on adding features to, and making them work for the widest possible market. But you talk about having a product stance and building a distinct personality in to these products. Why do you think this is important and what should you do if some people just don’t like your products personality?

Jon:
I think that’s the challenge, or may be that’s the compromise. If you have an opinion, if you build this product stance, some people won’t like it. You’re not going to get every single person to use it. And we can go back to that AirBnB example, and part of that for may parents was this sort of non-familiarity with the model, no cultural norm to back it up to. Part of it was also that it’s just not for them. Philosophically, they don’t believe in staying in someone else’s house. And I’m not sure we’re ever going to be able to change that. Like even if that cultural norm changes, they might not change, and that’s just fine. That actually does become a market segmentation exercise of like ‘do I have enough people left once I go through all of these stages to qualify and justify having a business.’ But this product stance is critical, otherwise you end up with an ambiguous sort of blandness. There’s a phenomenon in branding called ‘blanding.’ Which is where you sort of try to appease everyone and end up appealing to no one.

Do the things they do, rather than ask them about the things they do.

Derrick:
When you’re first implementing a product its personality won’t be fully formed, how can engineers go about starting to build a product whilst maintaining its integrity?

Jon:
I’m really not a big fan of this grip it and rip it approach to product development. You know where you just build something and get it out there. I am a big fan of iterative development cycles once there’s a product formed. Like at MyEDU they were deploying two to three times a day, and that’s a great method to be in. But when you’re starting you need to build a scaffold that is thoughtful. And that takes, almost like your spring zero, right. Like a lot of Agile teams have started doing this sort of pre-sprints where they focus on building the design work. Which is some typical stuff, wireframes and comps and then going in to some type of well-structured UI prototyping. But I think that that thinking has to be there otherwise we really end up with a Frankenstein. I think a lot of teams are now rebelling against, or beginning to push back on this, ‘just start! just build something,’ because they realise it ends up with some crappy products.

Applying the Techniques to Existing Products

Derrick:
How can those with existing products begin to apply some of these concepts? Can you build a personality in to a product if they didn’t previously have one?

Jon:
Yeah, absolutely. Absolutely. The key there is to perform the qualitative research. Because you can back in to this stuff right. It doesn’t all have to be there globally and holistically. You can just increment your way in there. You know, what a lot of people at large corporations have to do is just sneak it in. This is just the small quick hits. Do a little qualitative research, probably small, un-funded on the side. And then drive a small success. And then people say ‘hey, that’s really cool, I want some of that,’ and then you can get more success and so on and so forth. If you’re in the luxury position of having authority of a startup say, then you can choose this, you’re prioritising this over something else. So rather than this get out of the building mentality, which focuses on Q+A and questionnaires, get out of the building and start watching people’s real behavior. That’s actually, if you boil it down, that’s the fundamental. Do the things they do, rather than ask them about the things they do.

Recommended Product Design Resources for Non-designers

Derrick:
Beyond your book, what are some of the resources you can recommend for non-designers interested in developing more of a design-lead approach to product development?

Jon:
The key is actually anthropology, it’s kind of weird. Starting to learn what it’s like to research people. And a lot of that comes down to what we can bastardize and steal from anthropology circles. Ethnography is a form of applied anthropology, you know, Jane Goodall is sort of the quintessential example, living with the Chimpanzees, understanding their cultural norms and things like that. If you’re looking to get in to this stuff, then start to emerge yourself in culture, start to really notice how people live their lives.

Derrick:
Jon, thank you so much for joining us today. It was a pleasure speaking with you.

Jon:
Ok, thank you Derrick, I appreciate it.

Embedded Testers In Development Teams – Interview with Trish Khoo

December 17th, 2014 by Gareth Wilson

 

In this interview with Trish Khoo, Test Engineering Team Lead for Google My Business, we discuss the changing role of the tester in software development teams. She discusses the trend of embedding test specialists within development teams, benefits of the approach, common misconceptions developers have of testing and how to successfully introduce these changes into your organization.

You can read more about this and other testing-related topics on her blog.

 

Content and Timings

  • Introduction (0:00)
  • About Trish (0:30)
  • The Changing Role of the Software Tester (1:43)
  • Separation of Developers and Testers (6:30)
  • Maintaining Test Quality in Mixed Teams (10:48)
  • Getting Management Buy-In (12:54)
  • Ways of Incorporating Testing in Development Teams (14:27)
  • Recommended Testing Resources for Developers (15:48)

 

Transcript

Introduction

Derrick:
My name is Derrick, I’m joining from Fog Creek Software where for quite a while I held the role of support engineer. Now I’m helping with the sales team. So, Trish Khoo thank you very much for joining us today from Google out in sunny California where you’re the Tech Lead and Manager for the Test Engineering Team at Google.

Trish:
At Google My Business yeah.

About Trish

Derrick:
Great. So you were previously also in testing and development roles at Campaign Monitor and Microsoft, founded the Sydney Tester Meetups, and run the TestCast podcast, you write about testing on your blog at TrishKhoo.com and you’re a contributor to the Testing Planet and Testing Circus.

Trish:
Yeah, so that’s all true.

Derrick:
All true, yeah, you’re quite heavily involved. That’s fantastic.

Trish:
I’ve been moving countries a lot lately. I’ve just moved to San Francisco to join the Google headquarters. Prior to that I was working in London, also at Google, for about two years. Keep going back in time, I was in Sydney for about 7 years before that working at various places like you mentioned, Campaign Monitor, I also worked at a place called Salmat, Microsoft before that, I had a consultancy as well. So this is the journey that has lead me to be in Google working out of Mountain View. And I often go around speaking at a lot of conferences, mainly testing conferences, mainly speaking about software testing and software engineering and how the two can meet in the middle.

The Changing Role of the Software Tester

Derrick:
Over the last ten years have you seen the role of the tester change at Google and elsewhere?

Trish:
Yeah, so I guess for me personally I’ve seen software testing roles change in my own kind of role. Like, I’ve always worked in a siloed testing role and I think as I’ve gained more experience I feel like the roles I’ve had have been more overlapping roles in terms of, not just being specialised in a testing silo so much but being able to take on more programming skills, different tasks, take on things like release work, more software development work and just seeing the value of that. In terms of how Google has seen the software tester change, definitely Google over the last five years has gone through a huge change in terms of how the testing role was defined. Only as short as five years a go most of the software testing at Google was actually done manually. And there’s been a massive shift in order to take the software testing activity to being in software engineering teams and there was a new role created called Software Engineer in Test, which meant it was exactly what it sounds like, a Software Engineer who actually knows something about testing as well. Who was creating tools and increasing developer productivity from a testing perspective, so that means making software more testable, so that it’s easier to test and being able to get that fast feedback back to developers.

Derrick:
Why do you think these changes came about?

Trish:
I think there’s a few reasons. Like, first of all I think that if you have the separate roles of a manual tester and developer it becomes quite an inefficient process overall. Separating out the testing activity from the software engineering activity is, it creates this massive feedback loop. So say you finish implementing something in code, you send it to a tester to manually test. It takes them some time to notice it, get acquainted with what you’ve written, actually test it out and then give you that feedback. Whereas if you found a faster way to do that yourself, then that’s actually saved you and the project a lot of time. So, that’s one reason, just reducing that inefficiency in the process. I think another is that when software developers know more about testing it actually influences the way that they are actually creating software in the first place. They’re designing it for testability, and thinking in terms of what could go wrong and that has a huge impact on the robustness of the software that is created.

I think that software testing as a profession is a specialised field, especially when approached from a technology perspective, that sometimes is seen as a lesser role than the Software Engineering role. In terms of compensation, in terms of just status, and we really wanted to elevate that role to something that is better recognised and gets the recognition it deserves, in terms of being an area of expertise that actually takes a lot of time and study and practice to become proficient in. So that was another reason to just raise the bar in terms of bringing people in to that field and ensuring they’re recognized for what they do.

Derrick:
So you mentioned quite a few benefits to this role some of becoming more prominent and what these changes have introduced

Trish:
Yeah, I think that there, not so many benefits in terms of, like, I think that there are a lot of benefits in making the role a more technical role and a more well-rounded role in terms of skills, rather than siloing, you’re a manual tester now. There are a lot of benefits in terms of recognizing that both of these roles have overlapping goals. In terms of, saying not so much ‘you’re in charge of creating the software’, ‘you’re in charge of making it actually work properly’, but saying that both of you are in charge of making that software and making it work properly, and the goal is to create and ship product. No what skills do you both have in terms of reaching that goal now. You perhaps are a better architect in terms of creating the software, you perhaps are better at coming up with the test approach that’s going to help that get to a good place, but in terms of every day tasks and what you can do, there’s a lot more leeway in terms of the scope of what each person can contribute to that team and in terms of value.

Separation of Developers and Testers

Derrick:
There’s a traditional way of having QA, or testers. Devs just don’t have the right mentality to effectively test their own code – ‘devs build stuff, testers break stuff.’ Do you agree with that things should be separate?

Trish:
Yeah, I’ve actually heard that excuse quite a lot and I don’t really agree with it. I think that, I do hear quite a lot of excuses from developers who aren’t used to testing, in terms of why they don’t think that they need to take a more active role in it. And I think most of the time the first mistake that developers make is in thinking that testing is supposed to be easy. And then they think ‘well it doesn’t seem that easy, so it’s probably just something that I’m not supposed to do or something that is impossible to do right.’ But testing is in fact very, very hard, especially in terms of, if you haven’t done a lot of it before in your project and there’s not a lot of tests there, the code just isn’t written in a testable way. So there is actually a mountain of technical debt to be cleaned up there that needs to be recognized, before you can say ‘ok, lets start testing now.’ And another common excuse I hear is that if I start testing then it will actually take more time, so I just have to let my project manager or boss know that if I do testing then it’s going to slow down your project. But in fact, that’s also a fallacy, because yes ok, if there’s a mountain of technical debt to clean up then you are going to slow down in the short term, but in the long term, in terms of project time, the additional time you’re writing tests during code creation surprisingly makes it faster in project time, because by the end of the project you aren’t going to find as many bugs. So you’re not going to waste any time debugging, and fixing, and delaying the project right at the end, which is the most stressful time of the project.

Derrick:
It sounds like you’ve come across developers who haven’t wanted to test, how do you go about handling that?

Trish:
I think it’s difficult if you’re in a siloed role, as I have tended to be, just about the entirety of my career in testing. It’s really difficult to go to somebody in another siloed role and say ‘hey, this is how you should do your job,’ I think that it’s best to be able to find developers on your team who already embrace that and get them to be advocates for this new approach. Ideally in has to be top-down, it has to come from management in order to really convince people of the benefits. It’s not so much about getting the stick out and saying ‘you have to write tests or else,’ but just showing them why this is useful right. Like for some people it has a been an easy sell, because they just haven’t known how to do it and you can show them ‘you think this is difficult, and it is difficult, but here’s what it is going to achieve in the end.’ I had a great quote from a developer I work with who said that he thinks that ’tests are protection of his code from other developers,’ which I thought was a great way of putting it.

Derrick:
That’s an interesting way of putting it for sure, yeah.

Trish:
I think the other mistakes that developers often seem to make is when they think about testing, is that they think that testing is for finding bugs because that is one side effect of testing. But, testing is just as much about describing the behavior of the code and also just setting expectations, and most of all preventing bugs. So I often hear the excuse in terms of ‘I haven’t ever seen any bugs that would have been caught by the test that you are telling me to write,’ and you know, that’s true for the moment, but what’s to say that it won’t happen in the future, your projects going to go through changes. And I’ve had developers to come to a new code base and ‘well, how am I supposed to know what any of this does because there are no tests in it that describe what it is meant to do? I can figure out what the code does, but I don’t know what it’s purpose is.’ So I think that there is a big mentality shift there, and there’s a stark difference between developers who are used to testing and see the benefits and developer who aren’t used to testing don’t quite understand it.

Maintaining Test Quality in Mixed Teams

Derrick:
So having the roles sort of change now, where the developers also test, if you will call it a sort of ‘multi-skilling’, some people might say it’s a ‘Jack of all trades, master of none’ type scenario, where the depth and quality of testing is reduced over time. What’s your opinion on that?

Trish:
There’s two parts of testing here that really need to be defined. I’ve heard some people describe it as testing and checking. There is testing, which we can describe as exploratory testing, where you are searching for answers to very broad questions. And there is checking, which is answering questions we already know to ask, so very binary things like ‘can I log in or not’, ‘if I click this button does the page explode?’ that kind of thing. But exploratory testing questions are more like ‘now that I’ve implemented this feature, does this existing feature work right?’ or ‘how do these two things work together?’ or ’what happens if I do this?’ I’ve got no idea, right. So this is a manual testing kind of task. And I think that people who are used to it, if they’ve practised it, they become more experience with it, and people find testers who are very, very good at that. And I think that it’s good to have these specialists on the team and I think it’s ok to recognize that we have generalists and specialists, in terms of people who are very good at one thing and OK at a lot of other things. So it’s almost like an old Dungeons and Drgaons game, where you’ve got your skill set and you say ‘I’m really good at this skill, I’m OK at this skill and really bad at this one.’ But I think that the thing to recognize is that testing needs to be a core competency of software engineering. It’s kind of OK to be OK at it, and have someone else on the team be spectacular at it, but the idea is that you should be at a minimum of OK at it.

Getting Management Buy-In

Derrick:
Earlier we sort of talked about selling testing to different people and you mentioned the importance of testing coming from the top-down. How do you get that buy-in and why should they take it seriously?

Trish:
I think that it can be really difficult and of course it’s going to depend on the individuals that are within your organisation. I guess that goes without saying. But the thing that I usually focus on is time to launch and the quality of launches. So if you do post-mortems in your company, and well, even if you don’t. You certainly know the latest disasters that have happened in production. Just pointing to them, pointing to your last stressful launch and just say that this can help avoid all of that, right. It’s going to make your process more efficient and just focus on the fact that you can have more efficient launches as a result of this. And pointing to big companies like Google, like Microsoft, like other large companies as well that already follow these practices and seeing the results from them. And just pointing them as example to say ‘hey, these guys are seeing results in this way, may be we can start following them as well.’ One thing that’s really good to illustrate, are the feedback loops. And having a separate manual testing role and separate development role, and how much time that actually takes in order to get a bug fixed. As opposed to getting that feedback loop shortened, and earlier in the cycle, perhaps even getting it automated, and just show the difference there in terms of project time.

Ways of Incorporating Testing in Development Teams

Derrick:
What are some of the ways one can start to move towards this testing change in your organization? Could they just switch or is there more to it?

Trish:
I think it is more of a cultural change than it is a process change and that’s what makes it very hard. A wise person said to me that she actually thinks that you can only really achieve this change once you have parity in your team between developers who fully embrace and want this to be the way forward and developers who aren’t there yet. So once you’ve got a 50/50 and you can tip the balance slightly over, then you can start to see change with a lot of pairing and a lot of advocacy from the side that wants this to happen. That was one person’s opinion, and another person just said that you just have to start doing it. It’s important for management to be very transparent – why is this happening, what the benefits are, and just say just try it for one project. This was done at Microsoft in that way, and there wasn’t a lot of panicking, there was some that were a little skeptical, but no-one was freaking out and when they saw the benefits, then they saw that this is a good idea.

Recommended Testing Resources for Developers

Derrick:
Are there any additional resources you might recommend to developers, who see this and want to do it. How would they start to learn more about testing?

Trish:
About testing, I can recommend a couple of books actually for starters. There is one called ‘Driven by Tests,’ which is very much focussed on the unit testing side of things, but it’s a very good book, I’ve had that recommend to me. Then on the exploratory testing side of things, there’s a book called ‘Explore It’ by Elisabeth Hendrickson, which is aimed as an exploratory testing guide specifically written for developers. So I heartily recommend that book as well.

Derrick:
Trish Khoo thank you very much for joining us today.

Trish:
Great, thanks very much for your time.


Looking for more?

Visit the Archives or subscribe via RSS.