4 clues on how to leave your job in style

Leaving in style is the best way to start your next job

Leaving in style is the best way to start your next job

“I hereby inform you that I will be resigning my position at…”. An employee is leaving the company. A few decades ago this would be brutal, like a wrecked marriage.

Today, however, few employments are for life. Instead, employers and employees are partners, helping each other to reach the next level. At certain point, it is only natural that you would want to grab that next opportunity.

In 2014, quitting your job is a natural part of how business works.

Don’t get me wrong: I’m not happy to see that our ways are parting. It’s sad, but I’m also proud that your years at our company has left you with the skills and know-how that qualified you for your next mission.

I know you will go on to make other companies great or even start your own some day. Nothing will make me prouder than seeing Iterate alumni as industry leaders in the future.

In the meantime, remember that it’s important to leave with style. Think of the notice period, whether it is two weeks or three months, as your final show.

Here’s how you do it:

Put in an extra effort. Nobody will be surprised if you find it a little harder to keep motivated. If, on the other hand, you use this time to go the extra mile, you will surprise and impress. Is there a better way to be remembered?

Say “we” – and mean “us”. Don’t say “you guys” when you talk about our company. There will be no doubt that your mind has already moved to your next job. Instead, talk about “us”. We will consider you a part of the team until your final day.

Be super social. Take part in everything that happens. Instead of going into hiding, double down on the social side. Friday beers and office parties, you are there, showing us that you really don’t look forwards to leaving this nice crowd. We want you to be there!

Stay in touch. If you hadn’t before, add everyone as connections on LinkedIn and maybe friends on Facebook. Ask for private email addresses, and remember to send a farewell email with your new contact information. As you quit, good colleagues turn into friends and business connections. We should be an important part of your network.

Follow this advice, and you will be remembered as a great employee. Professional, social and loyal to the last. I know our paths will cross again – until then I wish you the best of luck.

A very quick way to A/B-test

In discussions about A/B testing, everyone usually agrees that it is a good thing. To get started, however, somebody must first have the time and the resources to build the A/B test rig. It will take weeks, and will probably involve some interesting big data technology. Also, it usually never gets priority enough to actually get done.

Continue reading

Economies of Scala

As a consultancy, we’re always on watch to see what might be the next step forward in the field of software development. I usually find that paying attention to what our developers are playing with provides a good clue.

These days, many of them are toying with Scala, and they are eager to try it out on a project. I have challenged them to come up with compelling business reasons to use Scala on a project, but they have come up short.

I figured I would help them find a good business case for Scala.

For software companies in a tight employment market like the one in Norway, most technical advantages are dwarfed by one concern: Access to good developers. It clearly doesn’t matter what kinds of technical advantages a new language can bring if you can’t hire any developers to work with it. On the flip side, if you can bring great developers to your project, you’re probably in good shape no matter what language you have chosen.

The question, then, is what language should you choose to maximize your access to good programmers?

Continue reading

What seems to be the Problem, Solution?

Like so many others, you’re ready to start practicing Lean Startup and Customer Development. You’re about to start working on a new product or feature, so the timing is perfect. You sit down with a Lean Canvas and start filling it in. However, if you are like most of us, you will quickly come across the following obstacle:

You have already gone ahead and designed a Solution in detail. You’re also quite sure that it is good. Why go through all that work if you already know what to build?

The quick answer is that you may have built a Solution, but not a Business Model. You have to take one step back: Is there actually a Problem out there that my Solution is the answer to? Is the Problem important enough for Customers to pay for having it solved?

You can and should do Problem Interviews with potential customers even though you have a specific Solution in mind. First of all, it might inform you and enable you to make your Solution better. Having figured out the most pressing Problems will help you build a better Unique Value Proposition and thus improve the chance for success in the marketplace. Finally, if you figure out that your envisioned Solution does not solve any important Problem, you will have saved a lot of money.

Reverse-engineering a Problem from a Solution is quite possible. You have to get out there and do Problem Interviews, but you have to follow a few simple rules to succeed:

1) Don’t go out looking for confirmation. If that’s what you do, you will find it. Keep an open mind and do what you can to keep your hypothesis falsifiable and your interview scripts unbiased. The input you get will be very valuable when you decide to go ahead and build your product.

2) Listen to the customer, but don’t ask for advice. It’s very easy to show your Customer a demo of your Solution and ask him what he thinks. Pure politeness will require him to be positive about whatever you put in front of him. Find ways to test your hypothesis without leading the Customer to a given conclusion.

3) Get out of your own circles quickly. Interviewing friends and family is a nice way to get started and to iron out issues with your interview script. But they are not unbiased enough to build your conclusions on, and they are not likely to represent your Customer Segments well. If they have ideas for more people to interview, though, you will quickly be heading out of your closest circles.

4) Don’t give up too fast. Problem interviews can be discouraging when your Problems don’t resonate with the first Customers interviewed. However, your problem doesn’t have to be must-have for everyone. When you dig deeper you might be able to find a Customer Segment that feels your Problem more than others, and who really has the need for your Solution. They will serve as your Early Adopters and help you build your product.

That’s it. Put your Solution aside for the time being, and start testing to see if you have a Problem worth solving.

Developer’s DNA

“The candidates must have at least three years of Java development and experience with four of the following five technologies…”. This is how a typical request for consultants goes, both for public and private sector customers. It clearly favors candidates with long, stable assignments behind them. It seems to be commonly accepted in our industry that the most important quality a developer can bring to a new project is experience. That may not be such a good idea.

The underlying premise here is that training makes you a more effective developer. That may be true, but only to a very small degree.

The problem is that deep tool knowledge is not where the biggest gains are. Software development is just not that trivial.

I have seen teams that have success based on criteria that are different from this kind of experience. A developer with 4 different projects in a 2 year time span take along more good thoughts than one with 5 years of experience with the technology being used. A fresh graduate with nothing to defend often asks those stupid questions that makes the rest stop and think. One who is attending meetups and reading relevant blogs takes along experiences others have gained without having been there himself.

Efficiency is not first and foremost dependant on the speed with which you can code because you have long experience with a specific tool. Efficiency comes with the one who asks if we really need to use the framework we have taken for granted. It comes with the one that had heard of the tool that ends up saving the team for weeks of work. It comes with the one who takes the time to think clearly and simplifies our process and makes everyone more productive. The efficient developer thinks like an innovator.

Development is innovation, and the best developers are innovators. The good news is that you do not have to be among the very creative to think new thoughts. You do not have to be fresh from school to ask the stupid questions, and you do not need experience from many different projects to be able to draw on other people’s knowledge.

Continue reading

Iterate støtter Digitalt personvern

En stor andel av de oppdragene vi i Iterate utfører for våre kunder gjelder utnyttelse av de mulighetene et fritt og åpent internett gir oss – alt fra friheten til å eksperimentere med nye forretningsmodeller til selvbetjent saksbehandling og salg av varer og tjenester på nett.

I løpet av 2012 blir datalagringsdirektivet del av norsk lovgivning. Direktivet pålegger lagring av trafikk- og lokaliseringsdata fra bruk av telefon, mobiltelefon, e-post og internett. Med andre ord hvem som kommuniserer med hvem, når det kommuniseres, og hvordan det kommuniseres. Kort oppsummert vil det digitale personvernet bli mye dårligere enn ellers i samfunnet.

Som selskap har Iterate sjelden lagt seg opp i politiske diskusjoner. Et klart unntak er der lovgivning eller reguleringer truer våre verdier og grunnlaget for vår eksistens. Datalagringsdirektivet er et slikt unntak.

Det svake personvernet på internett vil utgjøre et hinder for kunder som ønsker å benytte seg av nettbaserte tjenester. Direktivet er et skritt i retning av et mer lukket og kontrollert internett og en trussel mot den innovasjon og nyskapning Iterate er til for å støtte og fremme.

I forrige uke la vi derfor ut en avstemning ut for de ansatte. Spørsmålet alle skulle ta stilling til var om Iterate skulle gi  NOK 10 000,- til foreningen Digitalt personvern, som samler støtte til en prøving av Datalagringsdirektiv i norsk rett.

Avstemning om støtte Digitalt personvern

Alle de som avla sin stemme var positive til dette forslaget. Vi har derfor i dag overført penger til Digitalt personvern.

Bestemor skal kunne bruke dette systemet

I går fikk jeg en interessant leksjon i det å representere kunden. Jeg satt på kundesiden i et møte i et nytt prosjekt som jeg er en del av. Leverandøren hadde sin første demo, med skjermbildeskisser og noe implementert kode. Systemet er det jeg vil kalle et ekspertsystem, hvor brukerne skal benytte seg av programvaren i sitt daglige virke.

Leverandørens foreslåtte løsning var svært intuitiv og det ville være vanskelig å gjøre ting feil. På den annen side var det lite effektivt, man måtte gjennom mange skjermbilder for å utføre operasjoner og mye informasjon lå gjemt. Det var åpenbart at mye av det de hadde gjort måtte forkastes.

Jeg spurte hvorfor de hadde gjort det på den måten. Da jeg hadde gravd litt i det, kom det frem at representanter fra kunden tidlig i prosessen hadde brukt følgende bilde: “Det skal være så brukervennlig at selv bestemor kan bruke det!”. Dette hadde utviklerne av systemet tatt mer eller mindre bokstavelig. Med en wizard-aktig flyt og få steder å ta feil kunne nok hvem som helst ha tatt det i bruk. For en ekspertbruker ville det derimot ha vært tidkrevende og lite informativt.

Leksjonen er at kommunikasjon er vanskelig og at bilder og analogier er farlig. Bestemor kommer aldri til å bruke dette systemet, derfor bør vi ikke bruke det som et bilde på brukerne. Heldigvis kjøres det med hyppige iterasjoner, misforståelsen ble oppklart på et tidlig tidspunkt.