Zoals (bijna) iedereen ben ik mijn schoolloopbaan begonnen toen ik nog heel klein was. En zoals (bijna) niemand ben ik nu pas gestopt met de studie – waarschijnlijk tijdelijk, maar toch. In dertig jaar is er veel veranderd in de klas. Dat kan ook niet anders, met de nieuwe inzichten die zijn opgedaan en nieuwe (ICT-)technologie. Toch moet ik zeggen dat ik geen fan ben.

In 1997 startte ik met een HEAO-opleiding aan de HES in Rotterdam. Elke maandagavond en woensdagavond les, en de zaterdagen en zondagen waren gereserveerd voor lezen en het maken van opdrachten. Er stonden flink wat dikke boeken op de verplichte lijst. Na de HEAO nam ik een educatieve pauze, tot het weer begon te kriebelen en ik in 2003 startte aan de Universiteit Leiden. Opnieuw dikke boeken. Nu, in 2011, is het grote verschil dat de dikke boeken verdwenen zijn. Dat wil zeggen: er is nog wel een lijst, maar niemand leest meer een boek. En ik geef de schuld aan PowerPoint.

Ik kan mij niet herinneren dat we op de HEAO een computer met projector in de klas hadden. Als er al een projector was, dan was het een overhead-projector. In mijn herinnering stond er een docent voor de klas die vertelde. Dat is nu hopeloos ouderwets. Het schijnt – en dit heb ik puur van horen zeggen – dat er op de kleuterschool al een beamer aan ieder plafond hangt. Doodzonde vind ik dat.

Wat is dan precies het probleem van PowerPoint? Natuurlijk gaat het niet om PowerPoint, maar om de manier waar docenten (en daarom studenten) daarmee omgaan. Guns don’t kill people, neither does PowerPoint.Een PowerPoint-presentatie geeft een docent het gemak dat hij een les thuis voor kan bereiden en zo een uur vol kan praten (60 slides lang). Een vaste structuur, met een vaste opbouw, met een vaste tekst. Weg creativiteit, weg spontaniteit, weg betrokkenheid van de leerling of student. En wat heb ik een berg slechte presentaties voorbij zien komen. Zowel qua inhoud als vorm. Serieus, de inhoud kreeg een zesje, de vorm haal de voldoende bijna nooit. Het absolute dieptepunt was overigens een meiske van amper twintig die anderhalf uur lang slides heeft staan voorlezen.

En dan de ergste vraag: “Meneer/mevrouw, staat de presentatie ook op internet?” En het antwoord is een volmondig JA. Docenten zetten de presentatie op internet, ter voorbereiding op het tentamen. Denk hier eens over na. Er is een vak, daar hoort een boek bij, en dan zet men de presentatie over dat vak (lees: boek) op internet. Dus de docent plaatst de belangrijkste punten van het boek (lees: samenvatting) in een overzichtelijk PowerPoint-presentatie op internet. Wat kun je dan verwachten?

Studenten zijn aartslui. Of efficient, zo je wilt. Een gemiddelde (Nederlandse!) student zal niet harder lopen dan strikt noodzakelijk. In deze situatie… Wie gaat dan in hemelsnaam nog het daadwerkelijk boek lezen. Heb je enig idee hoeveel tijd dit kost. Of beter gezegd: hoeveel tijd je hier mee verspilt. Het boek lezen maakt het verschil tussen een 8 en een 9. In Nederland is een 8 echt zeer ruim voldoende, Goed zelfs! Iedereen die in het hoger onderwijs achten haalt mag dik tevreden zijn met zichzelf.

Wie echt slim is, stopt met boeken koepen, en geeft een rondje in de kroeg. Da’s goed voor je netwerk, voor later.

In de tig+ jaar dat ik nu software schrijf, ontwikkelde ik een grote voorliefde voor het zogenaamde object-georiënteerde programmeren. En gelukkig is dit ook de dominerende trend onder software-architecten. Zeker met de beweging weg van het client-server-model naar het webbased-model heeft de tegenhanger, database-georienteerd programmeren, danig aan populariteit verloren. Begrijp mij niet verkeerd. Ik zie het nut van een database. Maar voor mij is de database onderdeel van de architectuur en niet het uitgangspunt.

Historisch gezien hebben databases altijd een dubbelfunctie gehad: gegevensbeheer en het bieden van allerhande functionaliteiten. Bij functionaliteit denk ik aan stored procedures, views, functions, triggers en (zelfs) default values. In een object-georiënteerde architectuur horen dit soort zaken niet in de database thuis. Als voorbeeld zal ik het meest controversiële punten nemen: default waarden. Gegevens komen in een database terecht omdat een object wordt opgeslagen. Het object wordt geïnstantieerd (ver weg van de database) en dient bij het instantiëren de juiste default waardes te krijgen. Hier zit precies de crux. Functionaliteit dupliceren over zowel het objectmodel als de database leidt tot discrepanties in de implementatie. De default waardes voor eigenschappen van een class kunnen anders zijn dan de default waardes van een corresponderend record in de database. Dat wil je niet, en des harder je een keuze maakt tussen OO en DB, des te makkelijker je het jezelf maakt.

Een database heeft voor mij de volgende doelen: data-opslag, controle op data-integriteit en performanceverbetering. Het eerste doel is gekscherend te illustreren. Wat gebeurd er met een in memory object graph als de stroom uitvalt? Het geheugen is kwetsbaar, dus wil je gegevens op een harde schijf bewaren. Data-integriteit is een allerlaatste controle of de data die in een applicatie beheerd wordt klopt. Zijn de gegevens en hun onderlinge relaties in overeenstemming met de opgestelde integriteits-regels? Tot slot hebben databases rauwe verwerkingscapaciteiten. Databases zitten simpelweg dichter tegen het ‘metaal’ en hebben minder/geen netwerkverkeer nodig bij het doen van bevragingen en bewerkingen.

Als OO-man heb ik voor mijzelf de volgende uitgangspunten op een rijtje gezet. Het zijn richtlijnen over hoe met een database omgegaan moet worden. Deze gaan verder dan het fatsoenlijk normaliseren en denormaliseren. Richtlijn 1 is hierbij: alle (of op z’n minst zo veel mogelijk) functionaliteit en business logic  in de software onderbrengen, niet in de database.

Om de database als concept recht te doen volgt richtlijn 2: neem databases serieus binnen de functie die ze hebben. Als voorbeeld. Een database zonder indexen is een goudmijn voor performance-optimalisatie. Gebruik ze dus. Gebruik ook contraints voor primairy keys, foreign keys, unique values, en waar je maar even kan. Gebruik referentiele integriteit! En houd veldlengtes zo kort mogelijk. Zorg dat je een goed database-administrator hebt, die wil en kan functioneren binnen een OO-architectuur.

Databases hebben een interne structuur van tabellen, velden, constraints en indexen. Deze kun je middels een GUI met het handje aanpassen. Richtlijn 3: doe dit niet. Maak nooit handmatige aanpassingen in het database-schema. Gebruik een migrations framework waarin alle schema-verandering chronologisch zijn gescript. Als je wijzigingen in meerdere databases wilt doorvoeren dan zijn migrations onmisbaar. Denk hierbij alleen al aan een ontwikkel- en live-database.

Richtlijn 4: bepaal hoe je vanuit de software met de database gaat praten. Zoek je harde performance waarbij je als programmeur veel zelf kunt en moet doen? of ga je voor een echt object-georienteerde aanpak? En in welke mate lijken de classes/properties op de tabellen/velden. In het eerste geval kies je voor het simpelere Active Record, anders voor een full-blown Object-Relational-Mapper (ORM). Oftewel: ADO-recordsets, Linq2Sql of Entity Framework (om binnen de officiele Microsoft productcatalogus te blijven). Wie nu nog wil klooien met recordsets, moet zich achter de oren krabben. Deze optie valt heel snel af. Linq2Sql en EF hebben verschillen, maar over het algemeen gezien worden de mogelijkheden van Linq2Sql gezien als een subset van die van EF. EF is daarmee echt de grote broer van.

Toen ik leerde om met databases om te gaan begon de oefening als volgt: CREATE TABLE tblPersonen… Dit is een fout dit ik nu niet meer zou maken. Richtlijn 5 gaat over naamgeving. Allereerst is het de vraag of naamgeving in programmatuur in het Engels moet of in het Nederlands. In Duitsland kan ik mij de nationalistische discussie voorstellen, in Nederland niet. Ik kies zonder enige twijfel voor het Engels. Wat je ook doet: volg altijd de conventies die gebruikt worden in het software. Is de naamgeving in de software in het Engels, dan is de naamgeving in de database dat ook.

De software is leading, de database volgt. Weinig discussie mogelijk. Dit geldt niet alleen voor de taal, maar eigenlijk voor alles. Ik ga uit van de normale conventies die gelden voor C# (volgens de Framework Design Guidelines). Naamgeving van tabellen en velden vloeit  voort uit die van classes en properties. Dus hou ik de volgende conventies aan:

• gebruik geen prefixen
• veldnamen zijn nooit dezelfde als de tabelnaam
• gebruik dezelfde namen voor velden die de zelfde soort gegevens opslaan. Voorbeelden: Order, CodeName, Name, Description, CreateDate. Denk hierbij aan interfaces als: IOrderable, INamed, enzovoort.
• kies tabelnamen die niet te veel op elkaar lijken. Bij de twee tabellen ProductType and ProductsType kun je er op wachten dat iemand een fout maakt.
• doe alsof de database case-sensitive is
• stel conventies op en houd iedereen hier strikt aan (net als in de software)

Tot slot zijn tabelnamen in het meervoud. Product wordt dus Products, met een s. Probeer Meervoud-enkelvoud combinatie te maken die alleen op de uitgangs-s verschillen. Dus niet People-Person, maar Persons-Person. Dit vereist soms wat creativiteit, maar het helpt later. Puur voor het gemak.

De vorige richtlijn gaat vlekkeloos over in richtlijn nummer 6: koppeltabellen bestaan niet. Deze richtlijn is niet geheel onomstreden, maar ik ben er desondanks groot fan van. Koppeltabellen worden gebruikt om relaties tussen records die een n-op-m-cardinaliteit hebben op te slaan. In zo’n geval wordt een nieuwe tabel geintroduceerd die slechts twee foreign keys bevat, naar de gelieerde tabellen. Een voorbeeld met twee tabellen: Persons en Groups. Hoe gaat de koppeltabel heten? Er is een conventies die zegt dat je de namen van de tabellen achter elkaar zet in alfabetische volgorde: GroupsPersons dus. Trouwens, dit is een koppeltabel met twee tabellen. Een koppeltabel kan ook vier tabellen koppelen. Hoe heet de tabel dan? Afgezien van de naamgeving is er een ernstiger probleem. Wat gebeurt er als die koppeltabel een extra veld krijgt? Wat is dan het verschil tussen een ‘normale’ tabel en koppeltabel. Daarom zeg ik: koppeltabellen bestaan niet. Beschouw een koppeltabel als een normale tabel en kies een naam die past. Bijvoorbeeld: GroupMemberships.

Alweer geheel vloeiend komen we bij richtlijn 7: gebruik geen samengesteld primairy keys. Alle tabellen hebben precies 1 Primairy Key field. Aangezien we juist koppeltabellen verbannen hebben (die per definitie samengestelde primaire sleutels hebben) is deze afspraak makkelijk te houden. Gebruik voorts unique-constraints voor data-integriteit. De veldnaam voor de Primairy Key is altijd Id, wat afgeleidt is van de property Id op de class. Handig als je classes met een Id de interface IIdentifyable (met 1 property..) laat implementeren. Kies als datatype altijd voor de GUID boven een auto-increment int (meer smaken zijn er overigens niet echt). Het belangrijkste voordeel van de GUID is dat je van een nieuw object de Id-property zet in de software, en niet in de database. Principeel doe je dit omdat het genereren van id’s functionaliteit is. Praktisch wil je wel eens een sleutel hebben voordat het object is opgeslagen, en niet pas nadat het object in de database zit.

Abrupt tijd voor een geheel ander onderwerp: meertaligheid. Amerikanen hebben het in hun gelikte demos altijd makkelijk. Een veldje Name, een veldje Description en klaar. Wij Nederlands hebben snel te maken met vertalingen. Het is mij opgevallen dat juist in Nederland ontwikkelde software het best is voorbereid op het in kunnen voeren van meerdere vertalingen. Waar een klein landje goed in kan zijn. Maar goed, I digress. Richtlijn 8 heeft betrekking op vertalingen van teksten. De velden Name en Description lijken het zelfde, maar er is een cruciaal verschil dat verder gaat dan veldlengte. De naam van iemand of van een object is in alle talen het zelfde. Mijn naam is ‘Florian’, in het Nederlands, Engels, Duits en zelfs in het Spaans. Mijn omschrijving (of bio) is per taal anders. Dat wil zeggen: de inhoud is het zelfde, maar de tekst is anders. Name is 1 veld; Description is meerdere velden. Goed genormaliseerd stop je vertalingen in twee tabellen: TextEntries en TextTranslations. Het veld Description wordt een foreign key naar de eerstegenoemde tabel waarvoor meerdere vertalingen worden opgeslagen in de laatstgenoemde tabel. TextTranslations hebben twee velden: LCID en Translation. De LCID is een algeheel gebruikte afkorting voor landen en culturen. Voorbeelden zijn: nl-nl, nl-be, en-us, en-gb en fr-fr. Houd deze afkortingen aan, ook als je slechts de het eerste deel (de locale) gebruikt.

Richtlijn 9 gaat ook deels over locaties, maar dan tijdzones. Gebruiker, software en database werken niet op één computer. De website-bezoeker zit in Australie, gebruikt een webserver in Singapore die in verbinding staat met een database op Schiphol. Een extreem voorbeeld, maar ik wil hiermee aangeven dat de vraag: ‘hoe laat is het?’ zo maar drie antwoorden op kan leveren. Daarom is het goed om de ‘tijd’ van één computer/server af te halen. De database-server is hiervoor geen gekke optie. Houd er ook rekening mee dat de database-server fysiek kan verhuizen naar een andere tijdzone. Sla daarom datums op in een tijdzone-onafhankelijk format, het UTC-formaat.

Tot slot (om netjes, doch bij stom toeval, op het ronde aantal van 10 richtlijnen te komen) twee losse tips. Soms zijn properties van de classes die je in een database op wilt slaan zo divers en onvoorspelbaar, dat er op voorhand geen mapping van de maken is. Als een NO-Sql-oplossing  overkill is, sla objecten dan geserialiseerd in de database op. Doe dit niet binair, maar kies voor een XML-formaat. Dit maakt het debuggen, en het maken van wijzigen velen malen eenvoudiger. Kies voor ontwikkelgemak als er geen zwaarwegende performance-argumenten zijn. Kies er om dezelfde reden voor om geen documenten en afbeeldingen in de database op te slaan. Hou deze op de harde schijf en sla in de database alleen het pad naar de bestanden. Deze tip geldt zeker waarneer je werkt met een web-applicatie.

Tips en inzichten zijn welkom.

Ik ben het boek Managing the Professional Service Firm van David Maister aan het lezen. In het eerste hoofdstuk legt hij uit dat een onderneming drie doelen kan hebben: winst maken, waardevergroting of een instituut worden. De eerste twee had ik zelf ook al bedacht, de derde is een mooie aanvulling.

Een ondernemer is ondernemer omdat hij/zij iets meer wil dan een vast dienstverband. Zeker in Nederland is het goed toeven als werknemer. Waarom zou je je nek uit steken? Wat is de extra bonus die een ondernemer verwacht te krijgen vanuit het ondernemerschap? Ik zeg hiermee niet dat een ondernemer altijd een bonus krijgt of hier zelfs ook maar recht op heeft. Het gaat mij om de motivatie van ondernemer. Ik ga er, voor het gemak, vanuit dat de ondernemer in kwestie een boterham verdient met zijn bedrijf en bovenop die boterham nog iets extra’s ambieert. Laat ik vanuit die gedacht de drie door David genoemde doelen toelichten.

Winst is een logische. De ondernemer streeft ernaar winst te maken zodat hij als ondernemer meer geld verdient, dan hij in loondienst ooit zou kunnen. Hij kan er ook voor kiezen het geld dat hij zou kunnen verdienen te investeren. Hiermee laat hij zijn bedrijf groeien. Mocht hij een koper vinden dan verzilvert hij de opgebouwde waarde. De Engelse term Capital Gain vat dit principe mooi samen. Tot slot kan een ondernemer een hoger ideaal nastreven. Hij wil iets opbouwen dat groter is dan hemzelf. Een instituut dat hem zal overleven.

Hoewel ik deze drie doelen logisch vind, miste ik er een. Er moest een vierde zijn. Ik had de typische middenstander (kruidenier) in gedachte. Geen van de drie, door David genoemde, doelen lijkt van toepassing. Er zijn genoeg ondernemers die geen grote winst maken, die geen groot bedrijf opbouwen en die van hun onderneming geen instituut maken. Komt dit doordat ze wel het doel hebben, maar mislukken? Ik denk het niet. Er is een vierde doel, en dat is vrijheid. Er zijn zat ondernemers die het allemaal prima vinden en voor wie vrijheid precies de bonus is die ze zoeken.

Ik probeerde deze vier doelen in een twee-bij-twee-matrix te plaatsen. De twee dimensies zijn als volgt: lange termijn versus korte termijn, en materieel versus immaterieel. Het is denk ik voor iedere ondernemer interessant om te bepalen waar hij in het kwadrant zijn bonus wil halen.

	materieel	immaterieel
korte termijn	winst	vrijheid
lange termijn	bedrijfswaarde	instituut

Een paar weken geleden sprak ik iemand die een probleem had met een zakelijke relatie. Hij vroeg mij hoe ik zoiets zou aanpakken. Wat zou ik doen om de relatie te repareren? Vrij direct antwoordde ik met de wedervraag waarom hij niet gewoon zou stoppen met die relatie. Dat was niet het juiste antwoord. En om eerlijk te zijn vond ik het ook nogal laf klinken van mijzelf. Sindsdien heeft de kwestie mij bezig gehouden en ben ik er steeds meer van overtuigd geraakt dat ‘stoppen’ een goed alternatief is. Misschien wel het belangrijkste.

Het eerste voordeel van het alternatief ‘stoppen’, is dat je er weer een alternatief bij hebt. Je hebt plots twee opties: stoppen en doorgaan (en de laatste in verschillende vormen). Door de mogelijkheid van stoppen aan je opties toe te voegen sta je niet meer met je rug tegen de muur. Je schept hiermee ruimte voor jezelf, in je handelen en in onderhandelingen.

Dat je het alternatief ‘stoppen’ beschikbaar maakt, wil niet zeggen dat je de optie moet gebruiken. Door te kunnen stoppen is ‘doorgaan’ geen ‘moetje’ meer, maar een vrije keuze. Je gaat door, niet omdat je moet, maar omdat je dat wilt. Door deze realisatie kom je (weer) in je kracht.

Nu ‘doorgaan’ een keuze is, is het belangrijk om na te gaan waarom je dat eigenlijk wilt. Je moet de voordelen van de relatie boven water tillen. Weten waarvoor je het doet. Dat geeft motivatie om in tijden van een conflict met opgeheven hoofd in de relatie te blijven en jouw deel van de deal goed uit te blijven voeren.

Maar als je weet waarom je in relatie wilt blijven, dan weet je ook wanneer je ermee moet stoppen. Er ontstaat een streep in het zand, die voor beide partijen zichtbaar mag zijn. Er is namelijk niets mis met grenzen stellen. Een tijdelijk disfunctionele relatie is prima, maar niet tegen elke prijs. En als jouw grens echt bereikt is? Dan is stoppen oké. Beter ten halve gekeerd en ten hele verdwaald. Al is het mijn pijn in het hart (en de portemonnee).

1. Geef aan welke functies beschikbaar zijn

Medewerkers zijn flexibeler dan ooit. Niemand is full-time verkoper, of full-time receptionist. Medewerkers vervullen veel verschillende rollen. Dat maakt het werk afwisselend en leuk. Maak deze flexibiliteit ook kenbaar in vacatures. Plaats op de bedrijfswebsite een lijst met alle rollen die binnen het bedrijf vervult worden.

2. Moedig open sollicitaties aan

Een vacature geeft een heel sumier beeld van het werk, en kan sollicitanten het gevoel geven dat er geen klik is. Het vinden van goede mensen is lastig. En ook als sollicitanten de deur plat lopen, wil je met zo veel mogelijk kandidaten in contact komen. Geef de gelegenheid tot een open sollicitatie. Zo kom je in contact met zoveel mogelijk werkzoekenden en kun je samen kijken waar de sollicitant van meeste waarde is.

3. Geef een salarisindicatie

Een vacature voor medior-consultant zegt niet zoveel. Wat is het verschil tussen een medior en een senior? 5 jaar relevante werkervaring; wat betekent dat voor de portemonnee? Sollicitanten hebben vaak een salarisrange in gedachte, deze moet overeen komen met het salaris dat het bedrijf in gedachte heeft voor een bepaalde positie. Al is het lastig om zo open te zijn, het geven van een salarisindicatie helpt goed om aan te geven hoe ‘senior’ een kandidaat wordt verwacht te zijn.

4. Gebruik social media om de vacature te promoten

Het vinden van de juiste kandidaat is een informatievraagstuk: de kandidaat weet niet dat er een vacature is. Gebruik alle middelen om informatie over de vacature te verspreiden. Niet ons hele leven speelt zich af op LinkedIn, Twitter of Facebook, maar het zijn nieuwe communicatiekanalen die tot onze beschikking staan. Gebruik ze dan ook. Vraag alle medewerkers in het bedrijf om zich aan te melden op de diverse social networks. Vraag hen de boodschap te verspreiden dat er een vacature is.

5. Bevestig de ontvangst van sollicitaties

Tot slot een tip die zo oud is als de weg naar Rome. Als je een sollicitatie ontvangt, stuur dan even een mailtje naar de sollicitant ter bevestiging. Een sollicitant steekt moeite in het schrijven van een nette brief of e-mail. Waardeer dit. Ga netjes om met sollicitaties. Ook als er geen match is. Deze laatste tip lijkt overbodig (iedereen weet dit toch), maar ik durf te wedden dat er meer imago-schade wordt opgelopen dan noodzakelijk is.

This posting is part of the partners@work series.

Whether you are a producer of high tech equipment or a service provider offering business advice, whatever you line of business, you will always strive to make your products and services better.Every company learns, researches and discovers. Per definition research costs money, a lot of money. And money is a good motivator to seek out other organization that have the same problems.

In general there are three ways of working with partners to share costs for research and development: sharing ideas, working on a common standard and joint product development.

Sharing ideas

Remember the story of the three blind people who touch an elephant? The first feels a tree, the second a hose and the third feels a wall. Only by communicating, they can fit the pieces of the puzzle together. Only by talking to others in the field you can gain a better understanding of the market place. Round table meetings and mini-conferences are great methods of getting the ideas flowing. Join existing expert groups. Or even better: start your own! In this way you, as the organizer, can direct the meeting to fit in with your goals. You, as the sponsor, will be seen as the thought leader. If you feel that a strong association with your company is not appropriate, then there is always the option of giving the group a it’s own generic name. When choosing this option, do stay in control and make sure you have the official status of lead sponsor.

Working on a common standard

Not many companies in the world have the luxury of being able to prescribe a new standard. Setting standards requires a lot of work. Developing, proposing and realizing standards needs the cooperation of many individuals and organizations. Working with partners is not optional, is not something you could consider: it is a must.

If standards are so hard to establish, why would you want to put in all the effort? Standards make life in general easier in a number of ways. The most important reason is that a standard is common language, an agreement on how stuff is done. It allows multiple parties to work together relatively independently. They work completely separately as long as they adhere to the standard that was set.

For any giving problem only one or a small number of standards will survive. Other standard ways of solving the problem, which seemed like a good idea at the time, will simply die. Your organization will only survive if your offering is build on top of the surviving standard. You better pick the right one. This means you can look for the dominant standard in the market and stick to that. Make sure your offering is fully compliant and tap into the existing market place with like minded clients. The other option, more riskier one, is to set your own standard. This option is obviously only possible in emerging technologies (the internet is a good example). Again it may be a good idea to develop the standard under it’s own name instead of your organization’s name. When you are setting the standard, you have to create a community – and later a market place – that is willing to accept you and adopt your standard. Your attitude needs to be very black and white: people are with you or against you; they are your partner or your enemy. If your standard gets adopted naturally the market will gravitate towards your products and services.

Joint product development

Finally partners can help to complete your product offering. If your product is good, but it could be even better, then it may be wise to work with partners who have the missing pieces. I am not saying that you have done a bad job developing your product; what I am saying that with a little rework you can integrate someone else’s technology or ideas in your product and open up a complete new marketplace. The concept described here goes further than two product that complement each other. When working together in research and development it means that your product and your partners product arc truly integrated. To your clients they work as though it is one product. Perhaps even marketed under a separate name.

This posting is part of the partners@work series.

Building a partner network is an effective way of focusing on a limited number of  activities: to do what you are really good at. To blossom as a company you need to not only develop a product, but also market, sell, support and promote it. You may opt to do all this yourself, but most companies do not have the resources, capability, capacity, time or simply interest to do so.

Most partnerships are oriented towards marketing, sales, service and delivery. You may find that is the same for your company, where your company has developed a product and works with partners in specific geographic markets to generate more revenue than would be possible when working alone. Good partners have an infrastructure in place which allows them to be faster and cheaper than you.

Apart from the efficiency and effectiveness that partners bring, there is another important reason for working with partners: the platform product.A platform acts as a standard on which other companies build their end products. Think of patents or high-tech/software standards like Microsoft Windows. Commonly the platform itself cannot be sold to end clients; instead money is made by selling products that are built using the platform. If your company has developed such a platform product it can make money by demanding royalties for use of the platform.

The more end products are sold, the more royalties are being paid. For platform products it is paramount that the platform is adopted as The standard. Note the capital T. The more acceptances the platform achieves from the large community, the more successful, popular, and revenue generating the platform will be. Building a partner network is the only way to achieve this goal.

In het verleden heb je iets gedaan en in de toekomst blijft dat voor ellende zorgen. In het geval van een geldschuld betaal je maandelijks rente over een in het verleden geleende bedrag. Dat zijn kosten die drukken op de winst. Het legt een hypotheek op je bedrijf. Toch is financiële schuld niet het grootste probleem.

Een onderneming heeft niet alleen te maken met geldschuld. Een onderneming bouwt ongemerkt verschillende soorten schuld op. Ik onderscheid financiële schuld, technische schuld, organisatorische schuld en schuld bij klanten.

Bij technische schuld wordt in de productontwikkeling gekozen voor een quick-and-dirty oplossing die voor de korte termijn voldoende is, maar in de toekomst voor problemen zorgt. Soms zijn de problemen in de toekomst zo groot dat ze onoverkomelijk worden en het einde van de Product Life Cycle inluiden.

Organisatorisch schuld is herkenbaar aan inflexibiliteit van de organisatie en een lage motivatie van de mensen die in de organisatie werken. Een duidelijk voorbeeld van dit soort schuld is een consistent hoog ziekteverzuim op de maandagen. Deze schuld ontstaat wanneer een manager niet strak genoeg grip heeft gehad op het bedrijf. In het verleden heeft men de lieve vrede willen te bewaren en bepaald disfunctioneel gedrag niet aan de kaak gesteld. Nu is dat gedrag de norm, is het verspreid door de organisatie en heeft het uiteindelijk de bedrijfscultuur beïnvloed. Organisatorische schuld is daardoor hardnekkig.

Schuld bij klanten werkt op een vergelijkbare manier als organisatorische schuld. Door eens een slecht product of dienst te leveren ontstaat schuld. Een leverancier van een slecht product kan een klant bijvoorbeeld minder makkelijk verwijten dat de facturen te laat betaald worden. Door scherp te sturen op de kwaliteit en afspraken na te komen wordt deze schuld voorkomen, maar hij is hardnekkig. Een klant heeft bij iedere gemaakte fout een argument in onderhandelingen. Een argument dat tot in het eind der tijden wordt ingezet. Lagere prijzen leidt tot meer druk op de kosten waardoor de kwaliteit onder druk komt te staan waardoor de vicieuze cirkel rond is. In tegenstelling tot organisatorisch schuld is schuld bij klanten in te perken tot 1 specifieke klant.

Jim Collins schreef in zijn boek Good to Great dat de geweldige bedrijven vaak geweldig zijn gestart en geweldig zijn gebleven. Hij schreef verder dat het heel moeilijk is om van een middelmatig bedrijf een geweldig bedrijf te maken. Ik denk dat dat komt door deze vier vormen van schuld. Een middelmatig bedrijf met financiële, technische, organisatorische en klantschuld zal een extreem grote uitdaging hebben om geweldig te worden. In tegenstelling tot financiële schuld zijn de andere drie niet makkelijk zichtbaar en daardoor subjectief. Het probleem hiermee is dat ze inwerken op het bedrijfsimago. Nadat de schuld objectief is weggewerkt zorgen ze nog steeds voor problemen. Deze realisatie geeft managers de legitimatie om schuld de kop in te drukken voor het te laat is.

Schuld is niet altijd erg. Soms is het juist goed om even schuld op te bouwen en daarmee op korte termijn een groter bedrijfsresultaat te realiseren. Zo realiseer je met horten en stoten groei en kun je netto meer overhouden. Het is aan de ondernemer om te navigeren op de balans van goed en slecht. Het is de uitdaging aan ieder ondernemer om te weten welke schuld (in alle vormen) hij heeft, dit tijdelijk te laten zijn en hardnekkige schuld af te bouwen.

Ik heb een goed CV, maar het is altijd even puzzelen in welke rol ik precies van grootste waarde ben. Ik merk dat het extreem belangrijk is om te weten wat mijn persoonlijke kerncompetenties zijn. Na diep nadenken en veel sparren met mensen die mij goed kennen (waarvoor mijn dank!) kom ik tot vier dingen die ik meeneem:

• Ik heb een ruime algemene kennis en ervaring. Met name over a) hoe bedrijven in elkaar zitten (processen, drijfveren, belangen, informatiestromen, systemen, formele en informele organisatiestructuren) en b) software en internet (de industrie, de trends, ontwikkeling van, verwachtingen, mogelijkheden en onmogelijkheden)
• Ik snap hoe mensen in elkaar zitten: wat ze denken, hoe ze denken, waarom ze de dingen doen die ze doen en welke blokkades je kunt verwachten bij verandering. Deze competentie komt erg van pas bij het managen van mensen, het verkopen aan mensen en het samenwerken met mensen.
• Ik geef mensen om mij heen energie. Voor mij is het zakelijk leven een spel waarin iedere speler wil winnen, en paradoxaal genoeg de winst het hoogst is als iedereen wint. Ik speel dit spel met een tomeloze en aanstekelijke passie. Ik weet mensen enthousiast te maken en te mobiliseren het spel in volle overtuiging mee te spelen.
• Tot slot ben ik mijzelf. ‘Ik ben ik’, en dat is ruim voldoende. Je weet wat je aan mij hebt, ik sta open voor kritiek en ben niet te beroerd mijn eigen fouten toe te geven. Dat is niet alleen fijn voor mij, maar ook voor de mensen om mij heen. Die kunnen daardoor, net als ik, helemaal zichzelf zijn.

Dit schrijvend realiseer ik mij nog sterker dat ik niet zomaar in een hokje te plaatsen ben. Misschien ben ik wel de Haarlemmer olie die in iedere organisatie nodig is. En heel misschien is dat wel mijn sterkste competentie.

Ik weet uit eigen ervaring dat het lastig kan zijn om goede mensen te vinden, waar het zowel zakelijk als persoonlijk mee klikt. Vacatures kunnen zomaar drie maanden open staan. En daarnaast is het belangrijk om een keuze hebben uit zoveel mogelijk verschillende kandidaten. In alle jaren dat ik verantwoordelijk was voor het aannemen van medewerkers leerde ik 1 ding: ‘always be hiring’. Werf altijd, ook als je niet direct openstaande posities hebt. Zorg dat je een continue stroom aan sollicitanten heb waar je als bedrijf uit kunt kiezen.

Er zijn een aantal dingen die je kunt doen om een continue stroom te houden. Allereerst: zorg dat de website actueel is, een positief beeld van het bedrijf geeft en het belangrijkste: dat er vacatures op staan. Een website die het beeld laat zien van een succesvol groeiend bedrijf, staat in schril contrast met de zin: ‘Momenteel hebben we geen vacatures.’ Als bedrijf wil je altijd in contact komen met potentiële kandidaten. Is het niet voor een directe behoefte, dan wel voor een behoefte in de nabije toekomst of om simpelweg contact te houden met de arbeidsmarkt.

Een ander punt heeft te maken met de vacatures zelf. Functies in organisaties staan niet in steen gebeiteld. Niemand doet 100% van de tijd hetzelfde werk. Een Sales Manager die zich 70% van de tijd bezig houdt met verkoop en de resterende 30% met HR? Heel normaal! Vacatures reflecteren dit beeld niet. Ze geven vaak juist een star beeld van de organisatie en haar HR-behoefte. Een vacature voor een full-time Project Manager zal iemand, die inhoudelijk en commercieel bezig wil zijn, niet aanspreken. Terwijl de organisatie met enige creativiteit heel gelukkig kan zijn met die topverkoper die ook nog eens goed kan organiseren.

Bij mijn huidige bedrijf hebben we er voor gekozen om alle mogelijke rollen op de website te vermelden. Deze zijn overzichtelijk en geven een goede indruk van het werk dat binnen de organisatie verricht wordt. Potentiële kandidaten wordt de mogelijkheid gegeven op een functie te solliciteren, en we geven uitdrukkelijk de mogelijk tot een open sollicitatie.

Personeel is het belangrijkst kapitaal van iedere onderneming. Wees er zuinig op en zorg dat potentiële kandidaten solliciteren. Always be hiring, of cru gezegd: pak de krenten uit de pap.