online markedsføring og webkommunikation

PointofMail

Noget af det, jeg synes, er rigtig fedt ved online markedsføring og webkommunikation i det hele taget, er den rige mulighed for at kunne spore effekten af ens kommunikationsindsats, så du hele tiden kan tilpasse og målrette din indsats. PointofMail er et essentielt værktøj for eks. webshopejeren eller andre, der benytter sig af e-mail kommunikation og markedsføring. Med Pointofmail kan du detaljeret spore dine e-mails – blev din e-mail åbnet, blev den forwardet, blev der klikket på et link eller blev der downloadet en vedhæftning? Alle disse og andre features giver dig kontrol over din e-mail markedsføring indsats og sætter dig igen i stand til at tilrette og raffinere den.

Pointofmail er desværre ikke gratis at benytte sig af, men deres priser er til gengæld aldeles rimelige – eks. $49.99 for et års abonnement med mulighed for at sende op til 5.000 e-mails per år.

Workflowy

Brug for hjælp til at holde styr på dine tanker? Har du svært ved at huske og overskue alt det indhold, der farer rundt i hovedet på dig? Workflowy hjælper dig med at organisere din hjerne på en mindmap lignende måde. Webtjenesten har et enkelt grafisk udtryk og er super simpelt at gå til.

Når du har oprettet din gratis bruger, kaster du dig bare ud i at oprette kategorier eller hovedområder. I mit eget tilfælde bruger jeg bl.a. Workflowy til at holde styr på min blog, hvilke indlæg jeg har i tankerne og hvilke webtools, der skal med i de enkelte indlæg. Stikordene eller kategorierne kan uddybes ved at tilføje kommentarer. Workflowy er intuitivt at bruge og det er nemt at flytte rundt på og omarrangere sine tanker. Endelig kan du også eksportere din workflowy lister, så du har en tjekliste eller et arbejdspapir udskrevet.

Hyper Alerts

Har du irriteret dig over, du ikke fik besked, når en bruger postede noget på væggen på din Facebookside? Eller når der blev kommenteret på ét af dine egne indlæg på din Facebookside? Facebook brugere forventer hurtigt respons, når de går i dialog på en given organisations eller en given virksomheds Facebookside. Umiddelbart skulle man synes, at en sådan notifikationsfeature burde Facebook selv have udviklet, men når de nu engang ikke har gjort det, er det godt at Hyper Alerts har gjort det.

Hyper Alerts er en gratis e-mail notifikationstjeneste, der, hver gang der postes eller kommenteres på indlæg på en Facebookside, som du er administrator på, sender dig en besked i din indbakke. Med Hyper Alerts kan du monitere indlæg og kommentarer på din Facebookside og hurtigt respondere. Hurtig respons signalerer, at du tager dine Facebook sides followers seriøst, og at deres mening er vigtig for dig. Dermed styrkes deres engagement og forøges din brandværdi.

Med Hyper Alerts kan du endda monitere andre Facebook sider end din egen. På den måde kan du overvåge og sammenligne din egen Facebook side med dine nærmeste konkurrenters. Tjek Hyper Alerts egen Facebookside for flere detaljer.

Our Groceries

Denne applikation har jeg brugt rigtig meget i den forgangne måned. Fruen og jeg har begge fået investeret i et par HTC Desire smartphones og har derfor brugt en del tid på at finde, undersøge og udveksle diverse mere eller mindre brugbare applikationer. Den vel nok mest brugbare app vi er stødt på er OurGroceries.

Applikationen er gratis og kan hentes til iPhone, Android og Blackberry smartphones. Applikationen er kort og godt en indkøbsliste, der kan tilgås af op til flere brugere og som opdateres dynamisk. Applikationen installeres og der knyttes en mailadresse til profilen, og listen kan nu deles med andre profiler.

Fruen og jeg kan så sidde om aftenen og lave en indkøbsliste i fællesskab og skulle én af os komme i tanke om, at der skal føjes yderligere til listen, føjes dette til listen, og den af os, der er ude at købe ind, sørger blot for at opdatere listen, inden man begiver sig ind i supermarkedet.  Jeg kan kun anbefale denne applikation, da den fungerer supergodt og den sparer os for en masse besvær i form af vi undgår irritationen ved at vi glemmer at købe bestemte varer.

TweetDeck

TweetDeck er ikke noget nyt program, men jeg har i løbet af den sidste måned genopdaget programmet og vil derfor gerne gøre mit for at udbrede kendskabet til programmet. For har du flere social medie profiler at holde styr på, er Tweetdeck intet mindre end genialt.

Selv har jeg to Twitter profiler, to Facebook sider, én LinkedIn profil og en Foursquare profil, og med Tweetdeck, kan jeg holde mig opdateret på tværs af disse social medie platforme samt selv opdatere mine forskellige profiler. Du definerer selv indholdet i og antallet af kolonner i dit Tweetdeck, så det passer til dine behov. Selv har jeg defineret fem kolonner til mine to Twitterprofiler – All friends, Mentions, Direct messages, New friends og så en kolonne med en søgning på navnet på min profil, da jeg dermed opsnapper mentions om min profil, som Twitter ikke selv fanger. Derudover er Tweetdeck også en applikation, så når du er on the go, kan du holde dig ajour med hvad der rører sig på dine social medie profiler samt selv opdatere dit sociale image 

Disse var mine 5 fede webtools for marts måned 2011, som jeg selv har haft stor glæde af  i den forgangne måned.

Har du et program, en webtjeneste eller en applikation, du er stødt på i løbet af marts måned, og vil du gerne dele det med andre?

Smid en kommentar og del webtjenesten, programmet eller applikationen med alverden – det kan anbefales 

Online Møde Og Fjernsupport Med TeamViewer

At kunne fjernstyre en PC eller Mac gør det lidt nemmere f.eks. at yde svigerfar fjernsupport, når han har problemer med mailkontoen eller når din bedste buddy, der hænger lidt i bremsen når det kommer til at være web effen, skal have hjælp til at konfiguration af hans iTunes konto eller som i mit tilfælde har brug for at holde et online møde for forklare og overlevere en designopgave til min mediegrafiker.

Programmet TeamViewer har hjulpet mig mange gange med at løse de tre situationer skitseret ovenover.

TeamViewer

TeamViewer er et stykke software, som du installerer på din PC eller Mac – du kan endda hente en udgave til din smartphone. TeamViewer er gratis at hente og som privat person er det gratis at bruge. Vil du bruge Teamviewer til virksomhedsbrug, er det selvfølgelig ikke gratis og der er forskellige schemes og licensmodeller.

Efter du har installeret TeamViewer, er du nu klar til at kunne fjernstyre en anden computer og yde fjernsupport eller holde et online møde. Når du starter TeamViewer op, ser du to faner i toppen – Fjernstyring og Møde.

Fjernstyring er her, hvor du kan logge på en anden computer, men selvfølgelig først når den anden part har downloadet og installeret TeamViewer. Når det er gjort, skal du have den anden parts Partner-ID og adgangskode. Efter du er logget på den anden parts computer, har du nu overtaget skærm og mus, og du kan hjælpe med det problem, som den person, du hjælper, nu måtte have. Fjernstyringsdelen af TeamViewer er ligetil, og det er ikke særligt svært for selv den mest webforskrækkede at finde ud af at installere programmet og oplyse brugeroplysningerne, så du kan træde til for at hjælpe og yde fjernsupport.

Online møde

Udover muligheden for at yde fjernsupport indeholder TeamViewer også en ganske udmærket online møde funktion. Ved at klikke på fanen Møde tilgår du online møde funktionen. Her kan du deltage i et allerede planlagt møde ved at indtaste mødets ID, du kan se en oversigt over dine møder, du kan planlægge møder eller du kan starte et spontant møde. For at holde styr på dine kontakter kan det anbefales at du opretter en konto ved Teamviewer. På den måde er det hurtigere at få sat online møder i stand med dine kontakter.

I online møde funktionen finder du en lang række funktioner, der understøtter og kvalificerer dit møde.

• Skærmdeling – fed funktion, hvor du kan dele din skærm med de øvrige mødedeltagere.
• Filboks – også en fed feature, som gør det muligt at dele relevante filer via drag-and-drop, der understøtter jeres mødeaktivitet.
• Min video – gør det muligt at aktivere dit webcam.
• Voice over IP – her aktiverer du din mikrofon.
• Konferenceopkald – har er det muligt at lave konferenceopkald med deltagere, der ikke har Teamviewer installeret.
• Whiteboard – giver dig mulighed for at tegne og fortælle under dit online møde.

Derudover er det selvfølgelig også muligt at chatte via Teamviewers online møde funktion.

The final verdict

Teamviewers online møde funktion kombinerer Dropbox’s mulighed for at dele filer, Skypes mulighed for videochat og telefonopkald over nettet med en lang række andre cool funktioner, der gør et online møde til en fornøjelig og ligetil oplevelse og som derudover også gør det nemt at yde fjernsupport. Jeg vil i høj grad anbefale Teamviewer – især til mindre erhvervsdrivende og iværksættere.

Alternativer til TeamViewer

Gennem min research til dette indlæg faldt jeg over et par alternativer til TeamViewer, der også kan bruges til at yde fjernsupport og til at holde et online møde. Jeg har ikke selv downloadet dem og testet dem, men efter at have læst nogle anmeldelser af de to alternativer, er jeg ikke bekymret for at omtale dem og anbefale dem.

Email Tracking Med Bananatag

Har du behov for at kunne lave email tracking? For at kende open rate og click rate på de mails du sender ud og på den måde blive klogere på, hvilke af dine kontakter eller modtagere af dit nyhedsbrev, der rent faktisk åbner dit nyhedsbrev eller din mail og endda klikker på dine links i mailen?

Email tracking, open rate og click rate

For en erfaren email marketeer er begreber som email tracking, open rate og click rate ikke ubekendte begreber, og det burde de heller ikke være for en mindre erhvervsdrivende, der bruger email nyhedsbreve til at markedsføre sin forretning. Ofte er pengene små og tiden ligeså, og det er vigtigt at holde fokus for at få det meste ud at begge. Derfor er der risiko for, at mange mindre selvstændige fravælger at arbejde med og optimere på deres email marketing, men der kan være meget omsætning at hente ved at kende og arbejde med effekten af din email marketing. Hvorfor bruge tid på at sende nyhedsbreve ud uden at kende effekten og værdien af det? Med Bananatag får du et gratis program til email tracking og til at tracke dine emails open rate og click rate.

Bananatag

Bananatag er en simpel måde at tracke dine emails, og på den måde finde ud af, hvad der sker med dine emails, efter du har sendt dem. Hver dag sender du vigtige emails – nogle emails bliver åbnet og af dem bliver der klikket på et eller flere links i mailen og endelig bliver en del af dine mails ignoreret. Problemet er, at du ikke har nogen idé om hvad der sker og hvilke af dine kontakter eller modtagere af dit email nyhedsbrev, der gør hvad.

Bananatag er et program, som du efter at have downloadet og installeret det, kan bruge til email tracking primært i Outlook, Gmail (dog kun i Firefox og Chrome browsere), men det kan også bruges i andre email klienter. Selv har jeg installeret og integreret Bananatag i min Gmail konto, derfor tager jeg også udgangspunkt i installationen til Gmail og samtidig kan jeg forestille mig, at der er mange andre iværksættere og mindre erhvervsdrivende, der bruger Gmail og de mange fantastisk brugbare (og gratis) muligheder, som Google tilbyder.

Sådan virker Bananatag

Efter du har installeret Bananatag tilføjelsen til din Firefox eller Chrome browser, vil du, når du er logget ind på din Gmail konto, nu kunne se to nye blå knapper. Den ene knap – Bananatag, ligger til højre for søgefeltet og er linket til din Bananatag konto. Den anden knap vises, når du klikker på Skriv for at skrive mails og ligger lige til højre for Send og hedder Track & Send.

Du er nu klar til at kunne lave email tracking på de mails, du ønsker ved blot at klikke på knappen Track & Send. Dvs. at hvis du bruger din Gmail konto til at lave masseudsendelser af mails, som eks. et mail nyhedsbrev, forfatter du blot dit nyhedsbrev og føjer dine relevante links til nyhedsbrevet og klikker Track & Send for at sende din mail og Bananatag registrerer, at din mail skal trackes sammen med at de links, du har defineret i din mail, også trackes.

Analyse af din email tracking

Når du er begyndt at tracke dine mails, kan du nu begynde at se på og analysere, hvad der sker med dine mails. Du kan enten vælge at modtage email notifikationer med din data eller du kan tilgå din Bananatag konto via Bananatag knappen til højre for søgefeltet.

Som det første du kan se, når du logger ind på dit Bananatag dashboard, er en overskuelig statistik over antal mails, du har sendt, hvor mange af disse mails, der er blevet åbnet og endelig hvor mange af de mails, der er blevet åbnet, der så også har klikket på dine links i den udsendte mail. Med denne viden ved du nu, hvilke af dine mails, der har den højeste open rate og den højeste click rate. Med den viden kan du begynde at optimere på dine nyhedsbreve eks. i forhold til dit nyhedsbrevs opbygning, stil og tone for på den måde at få mest ud af dine kræfter med maksimalt udbytte.

Metrics – dybdegående analyse af din email tracking

Du kan også få noget mere detaljeret data ved at klikke på menupunktet Metrics i toppen af siden. Her kan du se en opsummering af dine aktiviteter. Det kan være en god idé specielt at fokusere på kliks på links fra stationære vs. mobile enheder. Har du mange kliks fra mobile enheder, er det hensigtsmæssigt at dit site er optimeret til visning på en mobilenhed.

Du kan også se forholdet mellem links, der er blevet klikket på, og links, der ikke er blevet klikket på. På den måde får du viden om, hvilke links i dit nyhedsbrev, der er mere interessante end andre links. Igen meget brugbar viden i forhold til at optimere på dit nyhedsbrev. Endelig kan du på siden Location under Metrics få et overblik over hvor i verden dine nyhedsbreve bliver åbnet. Dette er selvfølgelig relevant, hvis du har fokus på det internationale marked.

Dommen

Jeg er ret begejstret for Bananatag, fordi det er ligetil at gå til at lave email tracking og fordi du på en simpel måde kan få en masse brugbar viden omkring open rate og click rate på dine emails og email nyhedsbreve. Især er jeg vild med integrationen til min Gmail konto, der gør det nemt at bruge Bananatag og dermed indsamle værdifuld viden og indsigt i forhold til min mail kommunikation.

Deployment. Deployment. Deployment!

A good deployment scenario can mean the difference between a successful product and a failing one. The same goes when you are talking about the QA effort needed to verify and stabilize product during development. Let me paint you a picture of a product which had a bad deployment scenario.

It’s an enterprise product which has a 3 server setup: A database server, a webserver and a client installation. 3 machines are needed for every build and almost every verification of bugs, except super focused  bug fixes only occuring client side. Those were just very rare considering it was a 30 developer team. The procedure was that the QA team had a room with a secluded set of client machines, a DB server and a webserver. Every morning a build engineer would copy the daily build to a USB stick, move it to the QA room and install the nightly build on all the machines for QA to start work. This procedure would not be all that long, maybe an hour every morning, but QA would be tied to this build all day, because the previous days build was wiped in this process. And further, if there was a blocking bug being introduced during the night, the entire QA team would be unable to use the room for the day and the build from the previous day was also gone.

So why would a build engineer be needed to install this product? Well, yours truly decided to make an attempt at installing this beast of a system using the installation manual. 107 pages of detailed installing, configurating and tuning was necessary, which meant only very few people in the company were actually able to do it. And woe on anyone if something messed up during this procedure, because the ensuing debugging effort required detailed knowledge of the entire system, Oracle, Windows and a direct line to a few deities would probably also be needed.

All of this had led the previous management to conclude that the proper way of streamlining the department was to make a bottleneck out of the build engineers (those guys also built the installers for this) and make QA “efficient” by having it all setup so they didn’t have to know about all this. Which obviously is to make another flawed process to circumvent the real problem:

DEPLOYMENT!

What needed to be done here was to empower the QA engineers to install new builds by themselves, or at least in teams sharing some servers, so they wouldn’t rely so heavily on one build all the time. 

And the REAL issue of making an installer which preinstalled everything through commandline parameters was one I howled and screamed about, which led to each team having their own deployment developer, building installers in the very first sprint of a product. This was a costly move in the short term, because many developers suddenly had to learn WiX, but the long term value of having an agile team which had no dependency on a single build engineer was much, much higher.

This is not the only time I have encountered this deployment issue. In my time as business intelligence consultant I went ahead and produced WiX installers for the entire deployment and build pipeline for several projects. Nobody asked for it, because they didn’t know how bad they needed it, but once done they could all see the inherent increase in quality just because the turnaround from fix to verification became lower. And being able to remove the mess a manual deployment can incur was a very big quality bonus too.

While writing this I realize I have been involved in deployment in virtually every job I have had, because I find it to be so incredibly important for the software process as a whole and quality in particular. So if you find yourself working on a product with a complicated deployment scenario which is prone for user failure (“this is not a bug. The user needs to RTFM when installing it.” sounds familiar?), then you need to be very, very vocal about the need to simplify your installers.

Is that manager really needed?

Yesterday I had a conversation with a guy who is working at a place where I was a development manager 5 years ago and it has really left me with something to ponder.

The background story is that the dev manager in the company, EDC, had been promoted to be IT Director and because we had talked before he called me and asked if I wanted to take over the dev manager position of a department of 16 developers (No QA, but how I handled that is a different story!). Anyways, I quickly found some gigantic problems in the infrastructure, architecture and people there, so I made a plan which I presented to my boss and the board and after only a little bit of discussion I got the go to execute on the plan.

Together with a few core guys and a few new hires I made, we started out on a huge refactoring of the systems this company used and things progressed. We changed the release procedures, the processes and the infrastructure, and as I retreated from actually doing much coding (managers need to get out of that as soon as they can), my boss gave me the dubious honorary title as “War Minister” in the board. My task there was to challenge and keep the chairman at bay, because no one else dared having discussions with him.

Well, this chairman was, and is, a very successful, charismatic man, who has been an extremely strong leader in his part of the company, which left him with a power that crippled people around him. Personally I don’t really care that much about perceived power, I just want to do things right, so I didn’t mind arguing with him, which led us to take over board meetings with heated discussions, which luckily often led in the direction I wanted to. The short lesson here is that the man was intelligent and just needed a strong adversary to bounce ball with. We were better off with each other because of it.

And so it went, the restructuring moved on, things settled and I became bored. The plan we had would eventually last 5 years, but since it was on track, I didn’t really have to do much about it. My main work became risk assessment of new features and often saying no to some people wanting a hack because of “business opportunities”, which also gets tiresome in the long run. I didn’t really see much need for me anymore and I couldn’t justify my salary, so I moved on.

Back to yesterday. This guy is a friend of mine and he rants about the state of the organization. No one takes responsibility, because the chairman’s orders are being followed strictly throughout the marketing and IT parts of the company. No one really feels empowered and so they become inane slaves who executes on work they know is wrong. My friend even directly told his boss there (who was a project manager lead when I was there) that he would not want to become any form of manager in an organization like that, because no one has balls.

And this all makes me sad. Do I really have to stick around doing so very little actual work to see things in the right direction? Should I expect things to fall apart just because I leave? Where did I go wrong?

One problem I might consider is that I did not have a suitable second in command. One who could take over from me. But in this very example I believed the project manager lead had the right attitude and could see the execution through the processes and tools I had started. At the time I also had a very strong, young team lead which I had hoped could be the driver of the technical changes, but alas, he ended up being railroaded and left 1 year later.

Was the plan I made not good enough? No, they stuck to it with minor changes. 5 years after I started, 3 years after I left, they delivered the last part of the restructuring.

Sadly the same thing happened in Scanjour, the company I left to join Unity. The guy who hired me there was a boss of mine in a previous time and he assembled a very, very strong management team of 5 people. For various reasons he decided to leave, and soon after 2 of the other management left as well, leaving it to me and the program manager lead to run the department for a long period. We did so with what we consider good success, we were strained, but we saw improvements all the time. Then senior management decided that we needed a director, we did not have influence on which it would be and we were not that happy with the new boss. Eventually by some weird coincidence, I and the program manager lead decided to quit on the same day. And since then the department and my QA team has been in decline. So that time the detour started with my boss leaving.

I’m not sure I’ve actually come to much of a conclusion while writing this. It is a bit of a horror for me that my mere presence is needed for my department to thrive. I consider it a personal failure that I have to be there, because my ultimate achievement must be to be superfluous and have a self-sufficient executing team. Maybe I did achieve that internally in my departments, but I didn’t prepare them properly for the onslaught of surrounding politics, which had a big effect in both EDC and Scanjour and maybe this handling of the surrounding is what I have to accept is my primary task and achievement, but my pride will always be with the work the employees in the department is doing.

To answer my own question: Yes, that manager is really needed. If things are going well in his department, and you can’t really understand why, assume that he is doing something intangibly right. He is needed.

Top-Down vs. Bottom-Up

When you have a position as a manager, you have power over a lot of people’s everyday life and you are accountable for their actions as well. So there’s a lot of responsibility on your shoulders to get things done and at the same time keeping your employees happy.

Making changes

All of this blog post really comes down to changing something. Usually this is a process change, sometimes including infrastructure or organizational changes. Doing this in the software development field is sometimes interesting, because you are the manager of intelligent, introverted and, with QA in particular, risk-averse personalities. Because of this particular set of traits, your changes will be met with scrutiny, discussion and sometimes suspicion and there will be few changes you make which will be unanimously well received by your employees.

Since you are very, very interested in keeping your employees happy and invested in the company, you want to ensure they are as empowered as possible. So you will include them in as many decisions as possible, let them make their own decisions and merely make minor corrections yourself along the way. You want to be a consultant for your team, someone setting the overall direction and letting your employees do their best within the confines of this direction.

Sometimes you even have to introduce changes which affect people outside of your own organization, which is a subject I intend to touch in another blog post, but this one is particularly focused on changes you make in your own organization.

We’ve already established that you want to make changes. You now have a choice to make: Do you want to make this change as top-down, using your power as a manager to get it through and cut through discussions or do you want to bring it up to a discussion, taking in opinions from your employees and possibly waiving the change?

Top-down

Using the Top-down method you gain speed. It is simply faster to get it done if there is a non-ambiguous goal which everyone just follows. Ironically, I find that the bigger the change is, the more people are affected by a change, the more you need to use a top-down approach to get traction on a change. Having 50 people organically adapt to a new process is just not going to work, so you have to do a management decision and inform people of the change. Don’t linger about a decision if you won’t reconsider it; you have to take responsibility for it, it is on your shoulders, you made the decision, it is your job.

Making change this way requires you to take full responsibility for the change and any outcome. If it fails, there is no way around pointing all 10 fingers your way, but if you are a manager of a department of some size, I assume you are already good with that.

You might face a problem internally with your employees if it is a change which is perceived badly by some of them. This is especially the case if you want to do something which will touch the “culture” of a company, where some who have been there long identify with this culture. In such a situation I usually think of this “You can’t fix a problem with the same resources which made the problem”. I don’t mean you need to fire everyone and start from scratch, but resources are anything from tools to people to processes, so if old-timers tell your change won’t work, you need to ask them some hard questions about why that change is any less bad than what they did to end in the mess.

Since you are taking on full responsibility for top-down decisions, you can’t make many mistakes with them. It really does have to be a good change you are implementing; otherwise you will be losing your employees’ faith in your ability as a manager, which will result in attrition or reduced productivity. The “goodness” of the change does not have to be immediately apparent, it might even cause a bit of stir and dissatisfaction in the beginning, but you should be able to see the positive effects after a few months.

Finally, making a top-down decision has 2 other effects. First, you set yourself up as a strong leader. Leading back to the self-confidence post, sometimes a department really needs a firm hand to get it running as a unit. The downside is that you might be perceived as a power-fascist, so use it wisely.

Bottom-up

Implementing changes bottom-up is a slower process, but also one where you don’t have as much friction. At least not much friction between yourself and your employees, but you might end up in a different set of problems where the team internally gets into discussions and grinds teeth. This only tends to happen in a dysfunctional group, so if you have interpersonal issue you must solve those before you allow yourself to implement bottom-up changes.

There are also situations where you don’t have a 100% clear picture of what the end goal is, in which case you will get much better results by empowering your employees to find the solution. There’s no need for you to give the impression that you are an all-knowing deity, when clearly they have a much better understanding of the “real” work, so you just give a direction for the change you want and let it play itself out.

Another bottom-up scenario is where you don’t have direct power over the people you need to get it done. In this scenario you need to play your cards through all the channels you have available, including your management peers, your employees, public mail lists and personal relationships with other discipline members. This is really where your ability to influence indirectly will be tested and there is no recipe for how to do that.

Using this approach is more about making evolutionary changes. It is smaller steps where you don’t know the exact outcome, but also one where you don’t risk as much of your personal standing.

Real world

In Unity R&D everything is very bottom-up. When I joined QA I needed to turn some things around fast and I did that top-down to get traction and it is only recently in the past 4-5 months that I have released this approach as I have seen the teams and their leads take on their own plans and fates. I did have a long talk with my leads about this exact problem of walking the line between top-down and bottom-up and my message was clear: Don’t be afraid of making the necessary top-down decisions when you have to. It is part of the people management job and something you must be able to do when you see the need.

Some of the changes I did top-down include the structuring of our test cases, the process we use for handling bugs and the organization I wanted to implement. I did not want to put those up for debate and I wanted them implemented fast. A LOT of other changes we did in Unity QA has been bottom-up and it is the preferred way to do them, more so as the team has become confident and able to execute efficiently.

My goal as a manager is to make as few decisions as necessary, leaving them up to the people who actually execute them. But I reserve my right to correct flaws and set them straight, top-down.

Is that manager really needed?

Yesterday I had a conversation with a guy who is working at a place where I was a development manager 5 years ago and it has really left me with something to ponder.

The background story is that the dev manager in the company, EDC, had been promoted to be IT Director and because we had talked before he called me and asked if I wanted to take over the dev manager position of a department of 16 developers (No QA, but how I handled that is a different story!). Anyways, I quickly found some gigantic problems in the infrastructure, architecture and people there, so I made a plan which I presented to my boss and the board and after only a little bit of discussion I got the go to execute on the plan.

Together with a few core guys and a few new hires I made, we started out on a huge refactoring of the systems this company used and things progressed. We changed the release procedures, the processes and the infrastructure, and as I retreated from actually doing much coding (managers need to get out of that as soon as they can), my boss gave me the dubious honorary title as “War Minister” in the board. My task there was to challenge and keep the chairman at bay, because no one else dared having discussions with him.

Well, this chairman was, and is, a very successful, charismatic man, who has been an extremely strong leader in his part of the company, which left him with a power that crippled people around him. Personally I don’t really care that much about perceived power, I just want to do things right, so I didn’t mind arguing with him, which led us to take over board meetings with heated discussions, which luckily often led in the direction I wanted to. The short lesson here is that the man was intelligent and just needed a strong adversary to bounce ball with. We were better off with each other because of it.

And so it went, the restructuring moved on, things settled and I became bored. The plan we had would eventually last 5 years, but since it was on track, I didn’t really have to do much about it. My main work became risk assessment of new features and often saying no to some people wanting a hack because of “business opportunities”, which also gets tiresome in the long run. I didn’t really see much need for me anymore and I couldn’t justify my salary, so I moved on.

Back to yesterday. This guy is a friend of mine and he rants about the state of the organization. No one takes responsibility, because the chairman’s orders are being followed strictly throughout the marketing and IT parts of the company. No one really feels empowered and so they become inane slaves who executes on work they know is wrong. My friend even directly told his boss there (who was a project manager lead when I was there) that he would not want to become any form of manager in an organization like that, because no one has balls.

And this all makes me sad. Do I really have to stick around doing so very little actual work to see things in the right direction? Should I expect things to fall apart just because I leave? Where did I go wrong?

One problem I might consider is that I did not have a suitable second in command. One who could take over from me. But in this very example I believed the project manager lead had the right attitude and could see the execution through the processes and tools I had started. At the time I also had a very strong, young team lead which I had hoped could be the driver of the technical changes, but alas, he ended up being railroaded and left 1 year later.

Was the plan I made not good enough? No, they stuck to it with minor changes. 5 years after I started, 3 years after I left, they delivered the last part of the restructuring.

Sadly the same thing happened in Scanjour, the company I left to join Unity. The guy who hired me there was a boss of mine in a previous time and he assembled a very, very strong management team of 5 people. For various reasons he decided to leave, and soon after 2 of the other management left as well, leaving it to me and the program manager lead to run the department for a long period. We did so with what we consider good success, we were strained, but we saw improvements all the time. Then senior management decided that we needed a director, we did not have influence on which it would be and we were not that happy with the new boss. Eventually by some weird coincidence, I and the program manager lead decided to quit on the same day. And since then the department and my QA team has been in decline. So that time the detour started with my boss leaving.

I’m not sure I’ve actually come to much of a conclusion while writing this. It is a bit of a horror for me that my mere presence is needed for my department to thrive. I consider it a personal failure that I have to be there, because my ultimate achievement must be to be superfluous and have a self-sufficient executing team. Maybe I did achieve that internally in my departments, but I didn’t prepare them properly for the onslaught of surrounding politics, which had a big effect in both EDC and Scanjour and maybe this handling of the surrounding is what I have to accept is my primary task and achievement, but my pride will always be with the work the employees in the department is doing.

To answer my own question: Yes, that manager is really needed. If things are going well in his department, and you can’t really understand why, assume that he is doing something intangibly right. He is needed.

Developer to Tester Ratio

As a QA manager you will need a ballpark figure for how many QA employees

As a QA manager you will need a ballpark figure for how many QA employees you want in your department. You are going to have to make a budget and fight a bit back and forth with your manager and the financial department, so you need be prepared with some arguments for what that number should be.

All of these considerations lead up to you making a goal ratio. It is a gut feeling approach you will need in the beginning and as your department materializes you can adjust to reality, but you need this goal in the beginning. I’ll go through some of the factors in this judgement.

Legacy

The difference between an old application with lots of integration points, working functionality and technical debt vs. a brand new start-up with a fully TDD’ed codebase is big when it comes to the necessity for QA.

A QA working on a legacy system will always have to sanity check older parts of the system; new functionality is likely to have new integration points with legacy functions and the developers are often touching code which was originally written by someone else. All of these factors call for more QA time on the system compared to a new codebase.

Testability

Are you looking at a monster monolith which requires a farm of 15 servers in different roles, or is it a desktop application you can install by copying a folder to the harddrive? Is the codebase modular with abstraction layers and unittest in mind?

The deployment issue is important, because the more you have to do to actually get to test a new build, the more time is used by QA to just get it running and the longer you have between iterations of builds. If you on the other hand can just pick up the output folder from your buildsystem and run the app, you can very rapidly test any features or bugfixes the developers may have.

If the developers are having lots of unittests in place, chances are you have a more modularized application. At least you will know that there are good opportunities for adding QA automation to the testing effort, which should change the composition of your team.

Automation

How much of the regression testing effort can you push to automation? And how big an effort will you have to put into it before you reap the benefits?

It ties into the testability mentioned above and forces you to think more in terms of composition rather than number of employees. That is, however, a good idea to think about before you go into the debate with the financial guys about your budget, so they see you have put more thought into the subject than just a number.

In second part of this post, I will go through more factors and show the difference between the Unity and Scanjour ratios I used.

Is that manager really needed?

Yesterday I had a conversation with a guy who is working at a place where I was a development manager 5 years ago and it has really left me with something to ponder.

The background story is that the dev manager in the company, EDC, had been promoted to be IT Director and because we had talked before he called me and asked if I wanted to take over the dev manager position of a department of 16 developers (No QA, but how I handled that is a different story!). Anyways, I quickly found some gigantic problems in the infrastructure, architecture and people there, so I made a plan which I presented to my boss and the board and after only a little bit of discussion I got the go to execute on the plan.

Together with a few core guys and a few new hires I made, we started out on a huge refactoring of the systems this company used and things progressed. We changed the release procedures, the processes and the infrastructure, and as I retreated from actually doing much coding (managers need to get out of that as soon as they can), my boss gave me the dubious honorary title as “War Minister” in the board. My task there was to challenge and keep the chairman at bay, because no one else dared having discussions with him.

Well, this chairman was, and is, a very successful, charismatic man, who has been an extremely strong leader in his part of the company, which left him with a power that crippled people around him. Personally I don’t really care that much about perceived power, I just want to do things right, so I didn’t mind arguing with him, which led us to take over board meetings with heated discussions, which luckily often led in the direction I wanted to. The short lesson here is that the man was intelligent and just needed a strong adversary to bounce ball with. We were better off with each other because of it.

And so it went, the restructuring moved on, things settled and I became bored. The plan we had would eventually last 5 years, but since it was on track, I didn’t really have to do much about it. My main work became risk assessment of new features and often saying no to some people wanting a hack because of “business opportunities”, which also gets tiresome in the long run. I didn’t really see much need for me anymore and I couldn’t justify my salary, so I moved on.

Back to yesterday. This guy is a friend of mine and he rants about the state of the organization. No one takes responsibility, because the chairman’s orders are being followed strictly throughout the marketing and IT parts of the company. No one really feels empowered and so they become inane slaves who executes on work they know is wrong. My friend even directly told his boss there (who was a project manager lead when I was there) that he would not want to become any form of manager in an organization like that, because no one has balls.

And this all makes me sad. Do I really have to stick around doing so very little actual work to see things in the right direction? Should I expect things to fall apart just because I leave? Where did I go wrong?

One problem I might consider is that I did not have a suitable second in command. One who could take over from me. But in this very example I believed the project manager lead had the right attitude and could see the execution through the processes and tools I had started. At the time I also had a very strong, young team lead which I had hoped could be the driver of the technical changes, but alas, he ended up being railroaded and left 1 year later.

Was the plan I made not good enough? No, they stuck to it with minor changes. 5 years after I started, 3 years after I left, they delivered the last part of the restructuring.

Sadly the same thing happened in Scanjour, the company I left to join Unity. The guy who hired me there was a boss of mine in a previous time and he assembled a very, very strong management team of 5 people. For various reasons he decided to leave, and soon after 2 of the other management left as well, leaving it to me and the program manager lead to run the department for a long period. We did so with what we consider good success, we were strained, but we saw improvements all the time. Then senior management decided that we needed a director, we did not have influence on which it would be and we were not that happy with the new boss. Eventually by some weird coincidence, I and the program manager lead decided to quit on the same day. And since then the department and my QA team has been in decline. So that time the detour started with my boss leaving.

I’m not sure I’ve actually come to much of a conclusion while writing this. It is a bit of a horror for me that my mere presence is needed for my department to thrive. I consider it a personal failure that I have to be there, because my ultimate achievement must be to be superfluous and have a self-sufficient executing team. Maybe I did achieve that internally in my departments, but I didn’t prepare them properly for the onslaught of surrounding politics, which had a big effect in both EDC and Scanjour and maybe this handling of the surrounding is what I have to accept is my primary task and achievement, but my pride will always be with the work the employees in the department is doing.

To answer my own question: Yes, that manager is really needed. If things are going well in his department, and you can’t really understand why, assume that he is doing something intangibly right. He is needed.

GTAC

Say what?!
But before making my “Halleluja!”, I have a bone to pick. I’m highlighting the automation in that sentence above, because I came away with a very weird feeling of witnessing a group of developers padding themselves on the back for being developers instead of testers. Yes, they were in many ways awesome guys, trying very hard to find solutions where bug prevention is the key. This is natural in a test automation conference. But I had two moments where I had to blink a few times to let it sink in.

First one was when Simon Stewart from Facebook told us about the cool work he has done in the build system, which he admitted looked a lot like the Google build system where he came from, and it was really inspiring, but he commented on the fact that there is no test organisation in Facebook, there are only developers. Say what?! 

To be fair, Simon did not seem to agree with the intelligence in that decision, and I certainly don’t. So yeah, you can have devs make tests, but do they LIVE for it? Are they PASSIONATE about testing? Will they actively research better ways to write tests and will they pay all the attention to the suites and how they execute? Will they wake up in the morning and think of testing or will they think of features? I want testers to live and breathe for this, not have it as a secondary afterthought.

I do, however, agree with the common sentiment that developers must write tests along with their production code. Especially unittests. As a Googler, Mark Trostler, said in his talk about making code testable “if you follow all these principles you can get away with not writing tests first, but why would you?”

Second one was a casual conversation I had with a Google Software Engineer in Test (sorry, can’t remember your name if you read this), who worked on Chrome OS. I asked how big his department was, he said there were about 400 developers and 15 testers. And no test engineers at all. No test organisation either. I’m afraid I impolitely stared at him for a few more moments than what was comfortable, because that just blew my mind. The ratio is insane in itself and the organization leaves the testers without a proper discipline. The SET didn’t seem particularly happy either.

In my book these examples are less than optimal, to say the least. When you test software you have a gigantic surface to cover and you need a lot of diversity in the way you attack the system. Diversity means you need people with different tools, different focuses and different skills and that usually means different backgrounds. If you hire only developers, you lose out on a valuable testing ressource: Experts in structured and exploratory testing. These guys find different types of bugs, often a lot of them and we need them desperately.

Whether we have the correct balance in Unity, where it is 1:1 between automation and manual or if it needs to be different, I can’t say for sure, but I surely know I will never have a department without test engineers.

Continuous Integration
Ok, enough ranting. Now to the awesome. Google’s first keynote about their build system and all the data they collect from it was just awe-inspiring. The amount of work they put into this thing is unbelievable, but the benefits they reap in terms of productivity is also huge. And the ability to have 15000+ developers working on one source repository in one branch with one head is a dream come true from a testers point of view. And this is on a codebase of >100 mio. lines of code where 50% are changing every month.

So what is the magic? Speed. Everything has to be fast enough to facilitate a pre-commit test, which uses trickery like incremental builds, caching of artifacts and massive parallelism to achieve the goal of being able to pre-commit test up to 60+ commits per minute during peak hours. This really makes it a great incentive for everyone to write tests for their code.

But that’s not enough. They also harvest all the data about the system and uses it avidly to both fame and shame developers into writing tests and making better code. Automated code analysis, code review systems, reporting to monitors with faces of people doing good or bad. Anything goes in the quest for increasing quality. That really tickled my nerve, so I’m going to do what I can to make this a reality in Unity.

Flaky Tests
Another big theme was flaky tests. Tests which returns false positives and are non-deterministic. A huge theme for any organisation which has a lot of automation, including Unity. At the talks there was a difference in how these were treated, going from tolerating them for shorter periods to complete non-acceptable. In Unity we adopt zero tolerance for flaky tests, so anything has to be investigated immediately and if there is a suspicion of having a bad test, we delete it or mark it as a known failure and decomission it until we can fix it. Flaky tests are toxic for automation; it’s a slow killer which deprives it of validity and renders everything useless.

Performance
When you have companies like Twitter, Google and Facebook speaking, you can’t avoid talking about scale and performance. The talk done by James Waldrop from Twitter was about how he created performance tests and made a framework which was able to create Twitter scale load on the system: 2.000.000 requests per second! This is an outrageus number and the fact that their systems are able to handle this kind of load is mindblowing.

Aside from direct performance tests, there was a theme all the way of speed in the tests. More tests, more parallellism, cloud execution and for Android: Emulators. The exponential growth of tests and test execution requires us to do something other than brute force, which was a very interesting topic for a talk by a Ph.D. student who worked as an intern at Google to make it possible to use heuristics to find culprit changeset in long running test suites. This is the kind of trickery we need to employ in the future to cope with the ever increasing amount of tests.

Worth it?
Hell yes. Conferences which gets you inspired are an investment you get back tenfold. Ideas are surging and I’m inspired to go home and DO something, which is great. I hope I will get a chance of attending again.

Metrics

Metrics are, and always have been, a subject on any test conference and any conversation between QAs anywhere. They are the basis of your reporting, the numbers you care about. The eternal question is always “What metric should I use?”

You get what you measure

A good old saying is that “you get what you measure”. I couldn’t agree more. I’m certainly convinced that you rarely will get what you hope without making some measurements so people can see the state of progress towards some goal you set.

The funny thing is that you don’t do it primarily for the purpose of control, you should do it for the purpose of making a positive story about the great things you and your employees achieve. It is a great motivator to see your team is doing well in the form of hard factual numbers. So if you find the right metrics to measure, you will see people trying to achieve them and end up with an additional motivator.

The backside of the medal is that if you use the wrong metrics, you can get some really demotivated employees if the metric is unachievable. Especially if you use negative reinforcement to achieve the goal, such as salary or bonus reduction. You also risk making a metric which contradicts your current process, which leads to chaos and confusion.

When deciding on a metric, you also have to consider how hard it is to get valid data of high quality. If it requires elaborate manual labour to get the data, you are asking for trouble. It will tire your employees, leading to neglect, data rot and demotivation. Sometimes you want to trade in some manual work for a set of data, you just have to be aware of it upfront.

So be very aware of what you measure and how you reinforce it. It can make you or break you.

How I do it

I’ll go through some of those I use and give my interpretation of them as well. I’ll also use the term dimension, which is a BI term used in data cubes for a way to slice a metric, eg. Number of Bugs sliced on Status=Active is the same as Active Bugs.

Number of Bugs

Most intuitive and common metric. But sadly also very easy to become obfuscated as the product ages, multiple versions are released and features gets closed or refactored. You can’t afford to have any discussions on whether a bug is really a bug (this was the case in Unity before we instated a very strict regime with only having bugs which were positively reproduced by a QA), because any report you make using this number will have a debate about the number itself instead of the conclusion you draw from it.

I want to slice this number on a set of dimensions:

Status: Active, Resolved (Fixed), Resolved (Duplicate) etc. should really be the same set of status used in any software project. Active bugs should never be assigned to a developer, resolved bugs should always be assigned to the person reproducing it when creating the bug and this person should verify the resolution cause before closing the bug.

Area: Which part of the application are these bugs belonging to? Bug clustering is impossible without this information, but it is also very hard to make the data quality of this dimension good. There’s a tendency to invent too many areas and mix platforms and areas, so a firm hand is needed on this.

Assigned To: Who has the bug assigned now. Can be aggregated to team level. Used for resource allocation and occasionally shaming people into action.

Version: You want to track the version in which the bug was registered. Newer bugs tend to get higher priority when you go through them all in a bug scrub and eventually you close out very old bugs because they never got enough priority.

Milestone: Purely for scheduling purposes, so you can make the burndown charts for release managers to track how the final stabilization is going.

Priority: A scheduled dependent number setting the priority within the current release or milestone. In Unity this is set exclusively by developers because we have no project managers. QA leaves the bugs after having reproduced it and converted it to a bug, but in other companies I have been used to be a member of a triage team consisting of a project manager, a developer and a QA which attended all triage and scrubbing of bugs.

Severity: In contrast to Priority, this should be a release agnostic number stating how severe this bug is for customers. Set primarily by QA.

Is Regression: Tracing how many regressions you have on an area, version or milestone is important if you have a codebase with a lot of dependencies and integration points between teams and developers, because this will highlight communication and process problems. You might start out by having QAs being frustrated about this without having any hard data and then you institute a more rigorous process of reproducing the bugs to set this flag.

Customer Found: Was the bug found by a customer? With the active community Unity has, I use this to identify clusters of functionality where QAs are finding too few of the bugs compared to how many our customers find. The community finds about 30% of the bugs on our 4.x releases, so we have sufficient data to make this a meaningful statistic. We recently found a cluster where QA simply wasn’t doing a good enough job and we are now taking active measures to relieve our customers of this pain

These are just some of the most important dimensions I mentioned here, I have a lot more in the warehouse I made. Combining these numbers and dimensions I can make a lot of ad-hoc analysis of the situation on the product.

Other metrics of interest I use are Google Analytics number of times an editor has been started. Number of test cases, manual or automated, on an area can help determine some rough coverage. Automation which has been disabled due to known issues or those which are known to not work on a specific platform. The number of customer reported incidents we haven’t touched yet, how many are converted to real bugs etc. etc.

The list goes on and on, but in the end, I don’t really measure anyone’s performance solely on metrics. They are indicators which have to be interpreted and this interpretation has to be in the context of the current situation in time, organization, goals and management, so you get a balanced picture of the numbers. “Lies, damned lies, and statistics” is something anyone can relate to, but don’t be fooled: Numbers make you credible like nothing else in a world of engineers.