Thank you, thank you, thank you.

Hello? Hello.

Hello.

What the f--? This is terrible.

We're a company from Edinburgh.

We're small, we're about 4 and 1/2 years old and we're going to talk about this tightrope between mediocrity and bankruptcy.

And basically what that means is we'll talk about some challenges that we have in terms of finding clients, or dealing with clients, or dealing with designs, coming up with ideas, or building stuff and development, in general.

We'll also show you some monkeys.

First off, I'm going to introduce myself, I'm Espen, this is me.

Wow, that's a big drawing.

I'm creative director, as you can see.

I'm not an illustrator yet, but it's pretty good.

I'm also going to introduce this fellow here.

Hi, I'm Bart, and I'm going to tell you how miserable life of developer is at Primate.

And hi, I'm Gordon McLachlan, I'm the managing director of Primate, and I'm going to talk about the wonderful world of clients and getting business and project management.

So before we really start, we want to talk a little bit about why we started Primate and what's the whole ambition behind this is.

Hands up if you've ever worked in an environment like this? A few? We all met at our previous employer and we felt like this.

I appreciate some of you might not be able to raise your hand because your boss is sitting right next to you.

We felt like every day was kind of walking into a factory.

We do the same templates, the same clients, the same churning out, so, you know, assembly line style of design and development.

And we wanted to do something different, so we want to create our own agency where we could approach things our own way, essentially.

So one night when we've actually decided we going to run our own company, we've sat down and just talked about everything we hate about web agency business.

And we felt really, really negative, so we've distilled it into three positive messages that soon became our vision for the company.

And that's the embrace progress, create for content, and be honest.

And one of the challenges we've had over the past 4 1/2 years is, how do we do really creative work and still get paid? That may seem obvious, but sometimes those two things conflict.

And that's where this idea of the tightrope comes in.

We're still working on the tightrope.

We don't want to end up doing mediocre work and just churning out those same templates just under our own moniker.

Equally, doing really creative work requires clients and it requires balls and it requires money.

And we need to find that money, otherwise we have no business.

So, speaking of business, I'm going to leave you in the hands of Gordon just now, he's going to talk about clients and shit.

So, clients and shit.

Yeah, very exciting topic.

The first thing, and probably the most important thing of any client and a business is getting work.

Clients are really the heart of every service agency and of every freelancer, as well.

And if you don't have clients, you don't have a business.

If you don't get paid, you don't make money, you can't earn a salary.

So they are incredibly imperative in that point of view.

And it doesn't matter how good you are at design, or development, or SEO, or any of the other things, if you don't nurture these clients, you don't find good ones, you're going to be happy, and you're not going to get paid, and you're not going to have a business.

So this dynamic is really the first challenge we face on our tightrope.

How do we find good clients and how do we get good work? And of course you don't just want to find any client, because getting work you hate, it's not going to make you happy, it's going to make your work suffer, as well.

So to achieve this, you've got to try to balance two things, one of which is building and maintaining relationships, which are very important.

And the other side is usually a very tedious kind of pitching and proposal and tender process.

We love all our clients at Primate-- most of them.

We've only ever fired one client and that was a hard decision, but it was something that had to be done.

It was just relationship that wasn't working, and they were trying to bully us and they didn't appreciate our time or our work or our knowledge, so we took the decision, we had to get rid of them.

And like I said, finding good clients is tough.

And we have this kind of dream image of what the perfect client is like.

They usually have to have money, obviously.

They might want to be in a sector you enjoy working in, if it's charity, food and drink, tech, or something like that.

You probably want them to have ambition, you probably want them to be really friendly and easy to get on with, and you certainly probably want them to respect your work and respect your time.

And the first few things are quite easy to quantify and qualify.

Like you can tell the turnover of a business, you can tell their profit, you can tell their marketing spend.

But how do you know what someone is actually like? And that's a challenge.

And usually you don't actually know what someone's like until you get into bed with them.

And we've had a lot of occasions at Primate where we've met people and they've seemed really great and really exciting and really interesting, then we start to work with them and you find out a few weeks down the line they're a complete nightmare.

So you got to try be picky, and that's a challenge on the tightrope as well.

Because if you're too picky, you'll have no clients, or grow no business, no money.

And if you're not picky enough, you'll just have really bad clients who will make your life miserable and won't be very happy.

And like I was saying, as part of this process of finding the client, you usually have to pitch, as well.

And I love pitching, I love the process of pitching.

But the whole process, the whole idea of it, is really terrible.

Something I'm sure most of you have done.

And the idea of a company going out and trying to source several agencies, maybe five or six or seven at a time, and get them to all come and sit around and prepare slides and presentations and work and then present, it's really crazy.

We kind of joke a lot, it's a bit like speed dating, that you have to go and stand in front of someone and then sell your work to them.

And as part of this, you usually have to do a lot of creative work up front, often unpaid.

And that's a difficult decision, as well.

How much time do you invest in the sales process? How much time do you invest in a pitch or a presentation? Because ultimately, you don't want to be under-prepared because then you're not going to win the job, but you don't want to be over-prepared, either.

And if you spend 10 days of work for every job that you're pitching for and only win one piece of the result, that's a pretty terrible conversion rate and that can have real negative impact on your business.

So that's difficult, it's very difficult to juggle.

An interesting example's a few weeks ago, we actually pitched for a big hotel chain with their headquarters in Brussels.

So myself and Espen and one of our colleagues flew over there for two days for a one hour presentation.

And before that we spent something like 10 days on creative work.

We put together visuals, we put together slides, PDFs, leave behind everything.

We had a really good feeling about the job, we had a good nod on it, so we thought, yeah, we're really going to invest in it.

And the whole project was worth a lot of money, it was worth 100,000 pounds, or about 130,000 euros, so it was sizable.

And we didn't win it.

We found out afterwards that there been six or seven other agencies pitching all around the world, from America, Belgium, and the UK.

And as good as the feedback was on our work, ultimately the client had chosen to go with their incumbent supplier, the person they had a relationship with already.

So take from that what you will.

On the contrary, though, one of our best clients is someone that we got when we pitched and we did very little work up front.

We simply went along and had a conversation with them.

And I think we did a few slides and we'd had a few visuals, we'd taken some websites and put on their logos, it gives them an idea, but we hadn't invest a lot of time in it.

And ultimately we just spoke naturally, honestly, and had a really great conversation.

And not only was a project worth quite a lot of money, but they've turned out to be one of our best clients in the respect that we've had such a great ongoing relationship with them.

And in fact, we've even teamed up on projects with them in the future.

So how much time do you spend? How much is enough? And that's a difficult question, I don't have the answer to that.

I know there's a lot of agencies out there, and a lot of really respected agencies they refuse to do pitches unpaid or refuse to do it at all.

But then equally, I've seen agencies in Scotland where we're based that we're going out with business, we're taking this approach, so it's really tricky.

We've only ever been paid to pitch once, and that was by an American company.

So certainly in Scotland and in the UK, it doesn't seem to be the norm.

And so whilst I feel like sometimes we've maybe lost a bit of courage by really going guns blazing at these opportunities with creatives and visuals, equally, I know that our competitors are doing it.

It's very hard to stand there and not have anything to show.

And ultimately I'm reminded of this quote by the ice hockey player, Wayne Gretzky.

He says you miss 100% of the shots you don't take.

I'm also not advocating that you should go out and pitch for absolutely everything you take, you have to qualify it.

I do believe if you don't sometimes look for the opportunities and explore where they go, you might end up with nothing to show for it.

So the final thing I want to talk about along the lines of clients is project management.

Or, as I like to call it, managing ridiculous expectations and stupidly tight budgets whilst appeasing clients, over-zealous developers, pandering to vain designers, and avoiding disaster in order to survive another day, earn a meager salary and still pay and impressive mortgage so you don't end up homeless and destitute.

Thank you.

[APPLAUSE] And the challenge here is, how much time to invest in project management? Too little and it's just chaos, too much and it's a huge burden.

You spend too much time just maintaining specifications and with change management and all these things and not enough time actually doing the things that matter.

We work in an Agile manner at Primate.

I'm sure most of you are familiar with that, I don't have time to really go in depth and talk a lot about even though it's something I'm very passionate about.

I stole this slide from Robert Stulle from edenspiekermann_, who I saw talk in Barcelona in July, and I really liked it as an analogy of how the whole Agile process works.

It's this idea that really your client is trying to get from A to B, and that's the problem you're trying to solve.

And so instead of just trying to build a car and start, and then running out of money and time and budget the end, and not having a car, or having a part of a car doesn't work.

What you actually do is build a product in phases.

So you start with a bicycle, and then you create a motorbike, and then you create a car if there's time and budget left.

And that really sums up to me and I really like that approach, because then the clients always have something that ultimately hits their objective.

Equally, the whole Agile process and methodology naturally promotes communication and collaboration, which, I think, is hugely important for clients and relationships and project management.

We don't have account managers at Primate, so though we do project management, all our team of six and seven people, they're hands-on with the clients all times.

We meet with them very regularly, we meet with them every spring, we talk to the a lot and we really involve them in the process.

Really great thing about Agile is it tries to avoid specifications.

If anyone here works with specs, I'm sorry, I feel really bad for you, but they are dreadful things that people don't read and are a real pain to maintain.

So doing less of specifications is a good thing.

Agile's just not perfect though, it's not a silver bullet and it can be hard to use on smaller projects.

If your data website only has a budget of 20 days, taking an Agile approach can be very tricky.

Likewise, it tends to promote this idea of the MVP, the minimal viable product, and sometimes you forget about the lovable product, the things that really matter.

But compared to what's out there, I still think it's the best.

Having said that, we've had some pretty bad experiences with it because we find some clients, not all of them, but some of them, as much as you try to explain Agile to them, don't actually understand what it is.

This is an example of a client who, the one we end up firing, actually, who, at the start, we talked a lot about it, we explained it, we explained the concept of ice box and parity and everything, and they said they got it.

And further on in the project we kept reiterating this and the idea that we had this brainstorm at the start and you might not get everything in the bottom of the icebox, and they got it.

And three months later they're shouting at me down the phone because they didn't have everything they want.

It didn't make me very happy.

And it's the idea that you still have to maintain the relationship and you still have to have a good client to work with, because they're going to struggle to prioritize their features.

They're still going to want everything no matter how much you explain to them that you might not be able to deliver it, or they might not be able to get in their budget, or something else comes along.

To aid our process we a couple of tools.

One of them is Base Camp, I'm sure you use it and know of it.

Another one's called Sprinter, which is actually a tool we've built ourselves in-house.

And these just trying and help and expand on the natural transparency in communication and collaboration that Agile brings.

And ultimately, like I said earlier, what we're trying to do is really spend more time on the doing and less time on the management.

And I don't mean managing us as in talking to clients and dealing with them, but less on the updating specs and spreadsheets and all the laborious things.

That just gets in the way of it.

But ultimately, it's still boils down to relationships and having a good relationship with the client, and Agile works very well for that, because it promotes, like I said, the idea of communicating with people.

So to summarize everything I was talking about in one idea, it would be, be honest.

It's an approach we take, and it works very well.

The more honest you can be with a client or with anyone, the better the relationship's going to be, the more honest you could be at the start, the more likely you're going to have clients who respect you, the more likely you're going to find the ones that truly you connect with if you try and be salesy and lie to them at the start, that's never a good-- never going to end well.

It can be difficult, though, because sometimes being honest is hard.

And particularly, if you're trying to make a sale and you have tell them something they don't want to hear, that's a difficult thing.

But still, be honest as much as you can.

So I've spoken for awhile about the boring side of things, and now Espen's going to talk about the more exciting stuff, clients and shit.

Design and shit.

So how many of you guys are designers? Hands up.

Great, so if you-- design on the web is often about, you know, CSS and debates about pixels verses ems and frameworks and SaaS and all those things.

To me, design is more about communicating an idea or communicating a piece of knowledge or communicating a user journey.

It's not so much about implementation, but is about the conception of ideas that we, as designers, have.

So I'm going to talk very-- I'm not going to talk all about implementation, really.

I'm going to talk about the kind of, the shift that's around design.

And it starts with this tightrope here.

As a designer we start with a brief, and then at the other end we want to deliver an idea.

And over that tightrope there's several challenges, and, I think, I could speak for a whole hour about this, but I think I'm going to choose two main things that we struggle with or that we-- the things that come up time and time again that sometimes stifle creativity.

One of them is content and the other one is best practice.

First of all, the C word-- content.

This is the process we had when I first started working as a designer.

I was a magazine designer, I worked in a publishing agency.

So we'd have maybe half to staff were writers and the other half were designers.

So we were pretty much an even split, and content was really, really important.

Naturally, when you do a magazine, someone has to write the articles, right? So the editor would go away or someone would interview person and write up a draft.

That would be passed on to the designer, who would then come up with concepts or images are illustrations or layouts, even, that suited that content.

At the end, I'd maybe go and ask the editor, can you tweak this headline, or do you have an idea for the little box that we can use here, or can we make this longer or make the shorter? And likewise, the editor might ask me to change the layout a little bit.

It was real collaboration, it was content and design together.

On the web a few years ago, maybe a decade ago, we got the CMS.

And the CMS changed everything in terms of content, which means it also changed the design process.

Nowadays a lot of us design templates without really knowing what content's going to go inside them.

We design these shells and we focus on making them really beautiful, because we can't really tie the headline in with this superb image if we don't know what the headline is.

So we pass our templates on to developers and builders and coders and then maybe, in our experience, if you're lucky, two weeks before launch or maybe two hours before launch, we get an email with shit loads of content, we'd have to cram it into our templates.

This way of designing changes the whole idea behind what designers can bring to a project, because when we don't have content, we start focus on the other bits like the buttons, and the drop shadows, and this gradient, and the layout, than this grid system, and this way of implementing stuff.

There's been little talk lately about style guides and modular design and atomic design.

Everybody know what atomic design is? Or modular design? It's the idea that you start with your little small bits, modules, like a maybe buttons and sign up forms or whatever.

You build up modules, and when you have enough modules, you could build a page, and when you have a page, you can build a whole section of the website.

But to me, that's kind of organizing design assets.

It's a really good process, but there's no ideas phase in that, there are no concepts.

There's no real creativity.

So I feel like, in terms of content, we have this tightrope.

On the one hand, if you don't have any content at all, you have meaningless templates.

They might look really sexy and then might be really responsive and nice and fast, but they don't mean anything until we stick any content into them.

And you're not adding any meaning to the content, because the templates is design beforehand.

On the other hand, if every website was like a brochure or magazine, you need a copywriter and you need an editorial designer to sit and work on every single page, and that's simply too expensive.

Our answer to this is a take content and bring it into the design process.

And it's not emailing the client and say, hey, can you send us a draft for this page? We do that as well, but when I work with ideas, I need to be an editor for a moment.

I need to be able to express my ideas and think about content along the way.

So, for example, if we're all designing a website for a lawyer firm, for example, and we have a kick-off meeting and we talk about their values and their ethos and they're like, yeah, we're different from all the other lawyers.

We're honest, we're bold, we want to do something different.

And you're like, that's great, I can help you with that.

And then the CEO goes, OK, that's brilliant.

Can we start tomorrow? That's superb.

Here's an image I wanted to use on the homepage.

OK, great.

Really different.

Bold lawyers.

Now, if this is your text, you have nothing.

You have an image and you have some text, but there's no meaning, there's just a handshake, the horrible handshake of death.

But, this is where we unleash our inner copywriter, this where you go OK, I see you really want that image, it's a little bit overused, but if you insist, we can work with it.

But we can invite something into this to make it more meaningful.

We can change the headline-- we don't do secret handshakes.

Suddenly you have something that is more intriguing, you actually making the user think.

Fuck you, Steve Krug.

We're writing idea into it and we're making this picture, the most boring picture in the world, more meaningful.

And it ties in with the values of the lawyer firm, as well, right? I'm miss this kind of thing online, I don't feel like we do to enough.

Synergy, this is a word that comes up a lot in corporate websites.

And sometimes, like with a handshake, you might be forced to work with copy that's seems bland and trite.

But you can do the same thing here, you can use images to enhance the meaning of the word.

So like a simple analogy of the flower and the bee might work, it's maybe a little bit obvious, but it enhances the meaning of all the words.

You're telling a story about two things coming together to create something that's bigger than themselves.

And of course, the big the disparity between your image and the text, the greater the effect.

Here's one example from the real world.

My colleague, Steve, did this.

It's for an organization that he's created called recreate, it's a space where mentors and mentees can come together.

On this page you could have had any picture of a hipster on a bicycle smoking a pipe with an iPad and that's a perfect image of a creative, right? Instead, he chose, this is actually stock photography, but he found these two pictures and he conveys this idea of the fusion of two minds.

It's not rocket science.

Is really simple and it's cheap.

It's not difficult to build, but it's meaningful.

This is a company called Active Payroll, we just launched their site a few weeks ago, and this is super boring stuff.

It's about payment system for companies worldwide.

This is from their about page.

And again, we could have had this really nice picture of all of them in the boardroom smiling and it could have said, about us.

But we had a conversation with them early on in a project and we talked about who they were and, you know, what's behind the scenes, how do you guys work? And they started talking about their DNA.

So we thought, OK, that's great, let's use that.

So we wrote the headlines for them.

And then suddenly, again, we could use stock photography where we could tie it in, we had this visual hook so we can create a synergy between the headline and the image.

And this is the last example, also one of Steve's designs.

this is the history page for a company that those cruises on the Loch Ness in Scotland.

And again, it doesn't just say, history.

It says, the deepest love affair, which was written by a copywriter based on Steve's idea.

And what Steve done here it's just so nice, like just this-- setting the type in a way that makes it sink into the loch, I think, is brilliant.

And again, it's simple.

If this was a template, it would be the same template as every other website out there.

Big hero image and some white text on the front.

But when you have this synergy between the copy and images, it really means a lot more.

So that's what I wanted to say about content.

And now I'm going to tackle best practice and the rule book.

I'm a little bit sad that Lisa isn't here anymore.

I thought her talk was really, really good.

But maybe some of the stuff I'll say, she would be really offended, because maybe not advocating we follow the rules all the time.

I think in our industry one of the best things is that we're really good at sharing stuff, right? We stand on stage, we write our Medium blog posts and we're on Twitter, and we share best practice and tips and hints and guides.

Sometimes, though, things get really, like, it starts to sound like commandments.

Thou shalt not definest thy line height in pixels.

Thou shalt not baseth thy breakpoints on device sizes.

Or recently, we've had some talk about this today, as well, thou shalt not taketh the name of the Lord, performance, in vain.

Do you know what I mean? So I might sit there and I'm designing a website and I'm thinking, OK, we've got three piece of content here, they're equally weighted, they're equally important.

So I need to I want to display them side by side.

This my starting point and I figure, this is good, people can see all of this at the same time.

And OK, thou shall beginneth with mobile, fine.

I'll start with mobile.

My navigation is a little bit too long, we all know what to do, we just condense the navigation into one icon and we can put that in-- [EVACUATION SOUND EFFECT] --no, OK.

Right.

No hamburgers, right? We'll stack the navigation.

Hopefully it's just a short navigation.

What do we do with the content? Well I think it's equally important.

I don't want a long, scrolling page, so I want to stick it side by side and people could swipe, you know? [EVACUATION SOUND EFFECT] Oh, OK The carousel.

Sad face.

[APPLAUSE] This is the tightrope of best practice.

If you take all this stuff and put it together, you have this massive Bible.

And if you follow that Bible to the letter, you're a fundamentalist and your site's become really boring.

They all look the same, they all work the same, and it's maybe some people's ideal vision on the web, but it's not mine.

Like, I want something that's terrible and wonderful and crazy and experimental as well as things that are functioning.

If you don't follow any best practice, you'll have Jakob Nielsen hunting you down and saying, your site is unusable.

So it's a real balancing act.

Ladies and gentleman, my name's Espen Brunborg, and I have a confession to make.

You see, I'm a Parallax uses.

It gets worse, I also use carousels and I use hamburgers.

Why are we so polarized around these things? What is it about it that makes you go, oh you can't do, that you can definitely not do that, if you do that, you're evil.

I don't really know, but plenty of us think we do, right? There's metrics, we can measure everything on the web, and that's brilliant.

You know, you have A/B testing, you can put your site up and you can get real feedback regarding how your users use your site.

And when we see something like 60% of users don't complete checkout process, or only 1% of users click through to the next slide of the carousel, it makes us feel good.

It makes it feel like we know this stuff and we have the answers.

But metrics from one site doesn't necessarily translate to another site.

And I think the answer to most design questions and challenges is this-- it depends.

It totally depends on your context.

So a lot of people think rotating banners evil and they should be removed immediately.

But I think it depends, it depends on the context.

How many people have a smartphone? Right.

It's a big carousel, right? The iPhone, Androids, iPads-- they're all carousels.

You just swipe from one slide to the next.

So it depends.

We did a carousel a while back for a company called Harviestoun, they're a microbrewery in Scotland.

And as part of our vision for their websites and their strategy was to really highlight the brewers, right? Because this is a small place and we wanted people to really connect with them.

So we had this photo shoot, and we shot all the brewers and try to bring out the personality and it was really, really good.

And we put this in a carousel.

We got nice copy written about them and we had funny things like their wrestling names and little jokes about them.

Really tried to bring it out.

And this was heavy, like it's, there's a massive background image, it's Parallaxed, obviously we're writing JavaScript, it was a real pain to responsify.

But people spend two minutes on this page.

It's the second longest time spent on the entire site.

Two minutes, and that's only one minute of load time.

That's a joke.

What I'm trying to say is that I think in this context, people obviously know how to click to the next slide.

But the most important thing is because of the photography and because of the stuff that we wrote, and because of the audience actually wanting to find out stuff, when you want to see the next slide, you will do something to try and find it.

So I'll finish by saying fuck the rules, responsibly.

Best practice is really good.

I really, really loved Lisa's talk on standards and the whole music analogy, it's fantastic, standards are great, this whole community's great.

It's good to share things, you know, and give each other advice on what works best, better than other things.

But if you have an idea that works for you or for your content or your audience or your device, but then Twitter says you can't do it, fuck Twitter.

Just try it.

This is the whole tenant for our design process at Primate.

We try and bring content into it, and we also think that if your content warrants it, you can break the rules as long as you know why you're breaking the rules, and in this case, it might be a good idea to try a carousel or a hamburger, et cetera.

Then we should go for it.

So I'm now going to leave you in the capable hands of Bart, who will talk about the murky depths of development, which is why we're all here, so sorry about the delay.

Yeah.

Development and shit.

So as you probably expect by now, we work with designers quite a lot as developers in Primate.

And I will politely say that this relationship is really interesting.

But the one that's been well researched and observed in the building is the one between architects and engineers.

And if you were coming from development background, you probably heard a lot about it in system designs and system architectures.

But I think when we go to front end, the analogy, the parallel, is even stronger.

Because on one hand, you've got an architect, whose main goal is to operate in this sphere of vision and aesthetics and emotions.

And on the other hand, you've got someone like me.

Front-end developer, who just has to build it.

You know, deliver to the real world, just like engineers have to deliver architectured designs.

And we have to deliver them on time and on budget, as well, which puts additional pressure on us.

But fortunately, we are not only delivering what designers created.

Sometimes we bring stuff to the table as well to enhance the creativity.

So like engineers did for architecture in suspension bridges or reinforced concrete and stuff like that.

We love these moments because we love our little toys, we love to share them, and sometimes designer are not really fussed about it, and we're like, yeah, OK, but I didn't see any application for that, but we need to keep trying because eventually, they will come back and ask for it.

Fortunately, we can tell designers off sometime and make them cry.

Imagine, Escher came to engineer and said, building me that staircase.

It's fine, I've just sold it to the client and drawn it five minutes ago, and you can build it, right? It's impossible, sometimes it's impossible to build something, at least for us, as developers, at least on time and on budget.

So we like these challenges, but we have to stand on the ground and do these reality checks during the design phase as often as we can.

Because otherwise, everyone will be blaming us that we've not been able to deliver that on time.

And I think the analogies between web development and construction industry and here because they operate in real world.

We know physics and we are got models bills and stuff like that in engineering.

In web that's always changing, we don't have anything to rely on.

Just like a few weeks ago we had to fix some back wave animation on one of the sides because it didn't work on iOS 9, something unexpected.

So for us, it's really this balancing act between what's crazy and what designers really want to do and what's achievable and unfortunately, sometimes uninspiring.

Because you don't-- technology's greatest when it's transparent.

People will see the design, they will appreciate design, but unfortunately very often they will not appreciate the build.

You recognize some building and you ask, who designed it, but you've never thought, like, who build it, really? Who made it stand for 100, or 200, 300 years.

So we've got all these cool things, different technologies.

We use technologies that's people in Silicon Valley will kill each other for.

But in Scotland, it's a completely different story.

You come to them and you say, look, I'm going to build you a Ruby on Rails site, and they will tell you to get out because they want Drupal or Umbraco or something like that.

But fortunately, some other clients simply don't care or they trust us with our choices and at that point, we know that we're going to have a really good gig.

But what's really interesting is that clients really don't care about-- at least to clients we have, they don't really care about the front end tech we use.

And it's really interesting, like, we've never won a client because we said, we going to give you, a living style guide, or we never lost client because we said, we'll try react, or we going to build it in Ember, or anything like that.

Nothing happened.

And it's really weird, because front end tech, sometimes I feel like a little girl who get lost.

Nope.

Let's call her Alice, right? So on one of her adventures to Wonderland, Alice met the Red Queen and they were standing of this giant field that resemble this big chessboard and Alice is asking queen, how do I become queen myself? And she's like, OK, fine, you just need to like run to that squared over there over the horizon and you'll become a queen, right? I can show you, it's no problem.

So she grabs her by her hand and they start running, right? Then they run faster and faster, and soon everything around them starts to blur and Alice can't feel her legs touching the ground anymore and they stop to find themselves in the same place.

And I bet some of you we feel like that when Angular2 comes around.

But the queen says it takes all the running to just stay in the same place.

And if you think about technology, how it evolves, web technology or even front-end technology, it evolves even quicker.

10 years ago, we didn't have a term Ajax, or it first appeared around that time.

There wasn't Spec, for sure.

jQuery wasn't around, really and you feel like jQuery has been around forever.

And even later on, we had some really cool things happening in the front-end, but just in recent years there's been a massive, massive explosion of new tools and technologies.

So going back to the Red Queen, beside being just a great story, you kind of a geeky psychedelia that both of Alice's books are full of.

It gave the name to the hypothesis in the theory of evolution called the Red Queen hypotheses.

And it states that for a chance of survival in ever-changing environment, you need to move faster than everyone else.

And it claims to explain couple phenomena, and one which is the advantage of sexual reproduction against asexual reproduction.

This is kind of the stuff that we do at Primate, quite a lot.

I mean, not literally, but-- if you think, sexual reproduction is all about like crossing genes to make your offspring survive and give them better chance.

And this is what we do.

If you think of our gene pool, our knowledge base we share in the office, and our offspring being the work we produce, we have to think about everything while working as developers.

So we will talk with designers quite a lot, try to understand the basics of design, things like grid systems, or vertical-written typography, things like that.

So we can at least understand what kind of message they try to communicate to the end user and find the best tools to use.

We also need to understand business side of every project.

Very often we juggle three or four projects at the same time, so we need to understand really what needs to be delivered by end of the week or for tomorrow.

And most importantly, we have to speak to our clients, because we, ultimately, deliver work for them and if we want to be proud of what we create, we have to think about it.

So all that means, really, that as developers, week need to step up and don't let ourselves push in the development dungeon where we put our headphones on and listen to the music at work.

We need to speak to everyone else around us, inside the office and also outside of the office.

That's the whole team that works on the project.

So we need to understand what they actually need.

Going back to the Red Queen hypothesis, the other thing that it claims to explain very well is the extinction of co-evolving species in this environment we all live in.

And if you imagine that this little monkey is us and the raptor is one of our big competitors, we're on the treadmill where we need to run faster than them so we survive.

And for us, running is really experimenting.

So in this wonderland of webfront, front-end web technologies, we've got all these magic mushrooms, cupcakes, brownies, portions, whatever.

Pipe smoking, caterpillars, you name it.

And we need to try all of them, or some of them, at least, to know what's happening.

Take, for example, responsive web design.

I'm not quite sure when exactly we've adopted it, but very early when we started company.

And thanks to that, just when our competitors were starting to realize that they need to start thinking mobile first, we already had like two years off proper portfolio work to show off to our potential clients of fully responsive websites.

So it's all about finding these trends, but not just because they trendy, but because you realize that there's something more in them and they going to help the business or they going to help communicate the design better.

So we're bouncing on that line between trying everything and never producing any work, and mustering just one thing while everything else changes.

And that's how being so small we would probably die.

So we try a lot of things.

And just to give you some examples, like in past 18 months, we've been through like three different build tools and we just solely trying to step away from the jQuery completely.

We are still using SAS, but we ditched Compass few years ago, unfortunately.

Although I still like the vertical written part of that.

We do things like a Sprintr, we've build it in Rails in probably like six weeks just to rewrite it straight after into the JavaScript almost completely.

And if you look at these two screenshots from Sprintr.

They're separate, completed two separate apps built in totally different JS frameworks, just so we could get a feel for what we can achieve with these frameworks, what are the limits, what is better for this use case? And I already know that I would like to ditch one of them and rewrite it in the other.

And makes you realize that tech is disposable after sometime.

It's a big pile of junk after a few years.

So have courage to dump stuff that maybe doesn't work, or maybe if things are getting better somewhere else, have courage to dumb things that are small, like tiny tools and libraries or bigger frameworks, even whole languages.

You can do it and you probably should.

Kong, our CMS from dreams, we've started building that probably like six years ago, or six years ago, a long time before we've started Primate, just for few clients on the side.

And it was great project.

We had everything, like visual editing, and it was six years ago.

We had to inline visual editing of content, these interactive blocks you could create pages of.

We even had to build our own WYSIWYG editor to do what we wanted to do.

And we had to stop because we realized that we are competing with things like Squarespace, or some kind of bigger projects we've lost a bunch of.

So we've understood that it was big, big undertaking and we couldn't just continue.

We still run few clients on this, but it's real difficult right now.

We've failed, right? We failed with Kong.

But failure is something that, I think, every developer should get used to, because you will feel that you're failing quite a lot.

And I bet every one of you who is developing websites or do any kind of development feel the same sometimes.

Just as bonus, this is a guy called [INAUDIBLE] he's from Jing Woo martial arts school, he's some sort of hermit living by the Great Wall of China.

And part of his daily regime is punching himself in the face continuously for like an hour or so every day just so he's ready when real punches land.

And you should do the same, you should practice failing.

If you do it more often, you'll get used to how you go going to respond in these kind of situations, because everyone fails.

I've seen broken HTML image from Gumtree.

And a few weeks ago, if you looked at Google Maps API page, it was completely broken.

Unreadable, unusable, everyone fails, we need to accept it.

So we need to balance between what's achievable and uninspiring and what's crazy and greatly communicates the vision of our designers.

Wee need to keep experimenting and failing every day just so we can embrace progress.

So we've spoken about design, we've spoke about development, we've spoken about clients, and I'm sure there's one thing you all really want to know, and that is, can you go for lunch? Well, we're not going to keep you much longer.

So we've come to the end of our talk and the end of the tightrope, and the question is, how do we feel? How are we doing? And we've started to realize that this tightrope that we're on is a business and the journey we're on, it doesn't end, and the stakes just keep getting higher.

Although we're doing good work, we're not doing the best work in the world.

I know we're not bankrupt, we're not millionaires, either.

And the stakes just keep getting higher, projects get bigger, salaries get more expensive, teams grow.

So it can be really tricky to manage sometimes, and sometimes we do sit and ask ourselves, what's the point of it all? What is the point? Sorry, is this on? What's the point of traversing a tightrope when there's no end to it? When we started, we had these three core tenants, and we built them into the company, right? We wanted to use modern technology because we were sick of just sticking with the same thing and never being able to do anything that was exciting and new.

We wanted to have a different approach to design and bring in some of editorial design from my magazine background into web design.

And we wanted to be honest with ourselves and with clients.

As cheesy as it sounds, the journey is more important than the destination.

Whatever the endpoint seems to be, at one point for us it was maybe let's get to the first year and see if we're still alive.

Well, we are.

OK, but then you have a new endpoint, and you get there and you have a new endpoint.

And so it never ends.

So for us, the important bit is to avoid this-- it's to have a place of work you can actually enjoy, you don't have to sacrifice your whole life every Monday and every Tuesday and every Wednesday.

It's to have a place that feels less like a factory and more like a family.

This is our six staff members and their wives and partners and their babies and their dogs.

And it's really important for us that I can, for example, go to the vet with my two dogs if I need to, or Bart can work from home with his daughter, or Gordon can kind of take half paternity leave, half working for a few weeks.

It makes sense because work doesn't just affect us, it affects our families, and our families affect us, as well.

So this is, for us, right now, this is what it's all about.

This creating an environment where we can just be happy and do exciting stuff at the same time.

So we're literally at the end of the talk, we have one more thing that we want to show you, and that will be the takeaway from this talk, so here we go.

[MUSIC PLAYING] Thank you very much.

Thank you.

[APPLAUSE] Thank you.

Wow, thank you very much.

Please, Should we sit down? The comfy chairs, gentlemen.

That's a good challenge.

Quite a few questions.

We won't get time for all of them.

---can sit in the middle.

Just chime in, they're not addressed to anybody, in particular.

Uh-huh.

And everybody's aware that you're talking about you, so you're not able to give generic advice to the world.

Sure, you can sit, Bruce.

Cool-- You can sit.

I'm ancient, so I'll sit.

Little bit older.

Code of conduct.

You sacked one client.

In retrospect, when you're thinking back up on the, presumably, the relatively grisly procedure by which you sacked them, was there, looking back, are there any early warning signals that you look out for now when you have new clients? I mean it's tricky to know.

To be honest, I wish we'd fired them sooner.

And I think you just start to get a feeling.

It was very positive we first met them, but then, like I said, I just slowly start to get there.

And I think the early warnings were the first moment when they are starting to have difficult conversations and it's starting to get tough, and they're starting to make noises like, they're not really understanding what we're doing with our time, or what they're paying for.

And I think it's tough.

And like I said, you're never actually going to know what someone's like until you start to work with them.

But I guess you do have to be aware that if you're having a relationship with someone and it is-- you are starting to argue, it's starting to get tense, then I think that's early signs that this is not going to last.

And if you're having difficult conversations and arguments after a month, I don't think you're going to be able to work with them in six months, because it's rare that that gets better.

Is that why or that one of the reasons why you adopt an Agile methods, because presumably therefore you're going back to the client relatively regularly and they're aware that you're doing stuff, you're soliciting input, they can see they're getting value for the month.

Yeah, that's the idea.

And also that they're getting deliverables and it's easier to part ways than if you're trying to fulfill a big specification for six months.

It's easier to just hand over and walk away if you have to.

But yeah, it works very well.

The whole Agile thing works well if we're dealing with clients.

If I might say as well, it's also a big challenge in terms of the hardest things to tell a client in terms of Agile is you won't to get everything you want, you won't get everything that you want now.

And we kind of say this, and it's particularly difficult before you won the job, and you go, hey, we could do a great website, but it won't be what you think it will be.

It's really difficult. And

even though we say it upfront, it's kind of needs reiterating and that's a tricky balance between being the negative realist and a positive agent to work with.

Also, if I may, when you're working on big software development project, Agile is quite simple.

But if you're working in project that's like only 20 days long, it's getting difficult then.

Because how do you actually iterate over 20 days.

So that's one of the challenge we see because we've got plenty of these clients.

I was going to ask that as well, because I imagine that most people in this room are familiar, at least, with what Agile is, even if they don't get to practice it.

But it's a long time since I've done any commercial web design.

But you have any resistance from clients? What is this? We're giving you some money.

Come back in six months and give me a website, don't bother me.

Funnily enough, we've found most clients actually like it, or at least at the point when you're talking to, pitching to them, they really like that idea.

They like that they're going to be hands-on, and they like that they're going to be part the processors and they're going to see what it's like.

So we find actually it helps as a sales tool.

Got you.

[MICROPHONE POPPING] Somebody's playing the drums, it seems.

Question four Espen and Bart.

Bart, you mentioned that-- I loved your metaphor with coming up with an Escher picture and him to the developer, build this.

Is it important, then, Espen, that, at least as a designer, if you don't code yourself, I don't know if you do, that you at least are aware of what's physically possible given the limitations of the web so you don't dream up something brilliant, and then Bart goes, oh, fuck off.

Yeah.

I think it not only important so that I don't dream of something that's impossible, but if the more I know about SVGs or animations or JavaScript, if I know that it's possible and I can just hack it together myself in CodePen or something, then I start to get ideas, right? Once you know what you can do with CSS animation, suddenly you start saying, oh my god, I could do that.

Instead of it being a limitation, just opens the door completely.

And you do get a sense of what requires JavaScript and what doesn't, which is, that can be a big difference sometimes, in terms of budgets, for example.

If you go back to this elephants picture, it's really about that, it's about sharing what we know.

And one of the things I really wanted to do when we started Primate's never say no to say no to designers, but unfortunately, it's not the case.

Sometimes we have to go in and say, like, look guys, is really great, we'd really love to build it, but we just don't have time for it.

I think one of the rare, one of the few pleasures of being a developer is disappointing designers, to be honest.

One of the things that makes life worth living.

Last question, because we're running out of time, is, why Edinburgh? Have come you're in Edinburgh? It's a nice place, I'm not dissing it.

I lived Edinburgh because my now wife moved to Edinburgh 10 years ago.

No, six? Nine? Nice years ago? It's a long time ago, and then I found a job, and two jobs later I was working with these guys, and then two years after that we started Primate.

4 and 1/2 years later, I still think it's some sort of cosmic coincidence that happened.

Because three people from three different countries meeting in the same company at some point and just having a chat and thinking, OK, we going to do it, we going to do it better.

Cheers to happy accidents.

Ladies and gentleman, Mr. Bart, Mr. Espen,

and Mr. Gordon from Primate.

[APPLAUSE] Thank you.

Thank you.