In 2002, I began working as an Oracle database administrator at a government agency. Most people in the Netherlands know about the agency because it processes traffic fines. Therefore, it isn’t popular with the general public, just as the Internal Revenue Service isn’t. If someone asked who my employer was, I kept it vague and said the government or the Department of Justice. It didn’t take long before something went seriously wrong. On my second day on the job, one of the production systems crashed after running the batch jobs, leaving the database corrupt. In hindsight, that was a bit peculiar. After three days of searching, which included a weekend, I still hadn’t found the exact cause. When the operator restored the backup of the previous evening, which was still valid, and ran the batch jobs, the database became corrupt again. It was probably a software bug, so I advised restoring the backup from the previous evening and upgrading the database software to see if that would solve the issue. Instead, the IT director declared a crisis and set up a multidisciplinary task force to address it.

The head of the task force was a corpulent project leader who decided we should find the cause, which I hadn’t uncovered. I just wanted to fix the problem. Every day at 10 AM, there was a meeting to discuss the state of affairs. Every day, I proposed to upgrade the database software to see if it would help. And every day, my proposal was brushed aside. I would have done it myself, but I was a brand-new hire and didn’t have sufficient access rights. And the agency used VAX VMS, an unfamiliar operating system, so I couldn’t install software or restore backups myself. Two weeks later, after the experts had weighed in and after hiring a database corruption expert from Oracle, the cause remained elusive, and managers were getting desperate. Finally, they were willing to consider my suggestion. And it solved the problem. It was a harbinger of things yet to come. During the review, they grilled me for not being interested in researching the cause. I was not a team player and said solving a crisis was more important because it was a production system, so the users needed it to work. And the upgrade demonstrated that it was a software bug.

If you had prejudices about the government, my employer didn’t dispel them. You expect red tape, risk-avoidance, rule-following, and the like. It was all there. One department excelled. If you made the request incorrectly, they would do nothing, even when it was clear what they had to do. You couldn’t disturb them between 10 and 11 AM when they were discussing the work. They didn’t seem to do much, so what did they discuss for 1 hour a day? Some colleagues may remember my so-called crusade against bureaucracy. I often made jokes about bureaucracy and solved problems while ignoring red tape. Still, we perform our job effectively and efficiently, as traffic offenders would agree. And results matter most. Governments are bureaucratic because they implement rules.

Everywhere you go, some people work hard, while others take it easy. I have seen people doing little in corporations for profit as well. At my first project at Cap Volmac, we did nothing for months. Still, I have the impression that the pace of work in the government bureaucracy is, on average, slower than in the private sector. It is hard to put a number on it, but there is a difference. There is less pressure. Decisions take time and require more meetings. This is not a representative picture of the entire public sector. Police officers and teachers may experience stress. But most bureaucrats live calm lives. The hours you work for your employer are working hours. Cap Volmac required me to invest private time in education and corporate meetings. Finally, government employment is more secure.

When I came to work there, another database administrator, Dirk-Jan, a senior who had done several other jobs and hadn’t been a database administrator for long, was already there. After two months, Kees arrived, and from then on, we were three. Kees had a technical background. A few years later, Rene also joined the team. The agency also hired a security officer, a guy in a suit who soon began to make our work harder with unnecessary procedures. For instance, we had to lock up our Oracle manuals in a secure location after work and bring the keys to the porter’s lodge. But our manuals were public information like Windows manuals. Today, you can find this information on the Internet.

At the same time, the system that processed traffic fines had a superuser named after the system itself, with a password equal to the system’s name. Several other systems had the same issue, so the superuser and its password were the system’s name. I notified the security officer, but, being a true bureaucrat, he had more important things to do, such as attending meetings, inventing procedures, and preparing management reports. He added the issue to his list. But an issue like that called for immediate action. And so, I contacted a few senior programmers, and together we fixed that problem.

There were other issues with access rights as well. As they would say in the Professional Skills course, ‘There was room for improvement.’ If a new employee came in, the service desk made a ticket stating, ‘Create user account X as a copy of account Y,’ and sent it from one department to another. Usually, it took two weeks for the ticket to pass through all our departments, and system administrators made errors along the way. Hence, account X was rarely identical to account Y. If people switched departments or left, the defunct access rights were usually not deleted. Perhaps the audit department had figured this out, as our management soon launched a role-based access rights (RBAC) project.

RBAC works like so. You have a role in a department. In ordinary language, it is your job. For your job, you need access to an array of systems. Your job description determines which rights you need, for instance, to read specific data or change it. As a rule, employees should not receive more access rights than necessary to perform their tasks. RBAC is about the rights an employee in a specific job role needs. Business consultants came in and defined job roles and access requirements. A programmer then built an administrative database. However, the database didn’t connect to our systems, so there was no guarantee that the access rights in our systems matched the administration. And if you know how things fare in practice, you know that the administration would soon become stale and pointless. People are lazy, prone to errors, and forgetful. That would change once the administration and our systems are connected. If the administration was wrong, people couldn’t do their jobs properly, so it had to be accurate.

In 2004, I began building DBB, an account administration system, using Designer/2000, while keeping the bureaucrats out of the loop because they would likely stand in the way and make it harder for me. Only my manager and a few colleagues knew about it. DBB automated granting and revoking access rights in our systems, the RBAC way. It took me nine months, as I also had to do my regular work as a database administrator. But when I was ready to implement DBB on the production databases, bureaucrats became aware of what was happening and tried to block it. In their eyes, this was wildcat development. There had been no meetings, nor were there piles of reports to justify it. In early 2005, I introduced it sneakily with the help of the people from the service desk who wanted to use it. They installed the DBB client programmes on their personal computers. And I was a database administrator, so I could install anything I wanted on any database.

The results exceeded anyone’s expectations, including mine. The service desk created the accounts, so the tickets didn’t have to pass through all those departments. We could issue accounts in one day instead of two weeks. The service desk could reset passwords on the spot instead of relaying the request to a department, reducing the time to reset passwords from hours to seconds. And the access rights accurately reflected job roles. So, once DBB was operational, the opposition crumbled, and DBB became a regular application, even though not an official one, which was an essential distinction for bureaucrats. And so, we had RBAC fully implemented.

The DBB logo was a drawing by my wife. She had made it for another purpose. It features several jokers grinning at a set of file folders. To me, these folders symbolised bureaucracy. DBB joked with the bureaucrats, who considered it a rogue system. Supposedly, I was one of those jokers, so I made one of them my avatar on the Internet. DBB was my love child, just like Fokker once was Jürgen Schrempp’s, and for a while, I was overly attached to it. I ensured DBB could survive if I left my employer by producing design documents and manuals. I also built DBB in accordance with accepted Designer/2000 practices. We employed Designer/2000 programmers to maintain DBB. However, I hadn’t followed the proper procedures when building and implementing it, so it never became official. If something went wrong, it was not a mere incident, as would be the case with an official system, but a reason to replace DBB. That is bureaucratic reasoning at its finest. Something went wrong once, which allowed a high-ranking bureaucrat to block further development of DBB.

There have been two projects to replace DBB. In 2006, the first effort stalled because the planners had underestimated the complexity of the matter. They might have thought, ‘If one guy can do it, how difficult can it be?’ In 2016, a new project team realised it was pointless to replace DBB, as it was doing fine, while doing so would have been costly. The newer Java systems ran on Postgres databases and used web access. They did not use DBB. Our management planned to decommission the old Designer/2000 systems so DBB could retire by then. By 2024, DBB finally retired after nearly twenty years of service.

Bureaucrats have a unique way of doing things. In the case of serious incidents, they began filling out a ticket in the incident administration and discussing who should do what, while I pursued the issue. And sometimes, I had fixed it before others had finished filling in their forms. And I didn’t bother filling in forms. The system for which uptime was the most critical went down the most often. The solution was to reboot the system, but the operators hesitated and waited for a management decision. I said, ‘Just do it!’ And then they did. If it went wrong, they could blame me. I didn’t have the rank to make the decision for them and would have received a grilling if it went badly. But time was of the essence. The database was on an Oracle RAC cluster, a cutting-edge technology that had yet to mature. And that was so for a reason. It had to be operational at all times.

American software corporations like Oracle usually launch their products fast and aggressively market them. If customers buy them, they use the sales proceeds to improve these products and make them work properly. That gave American software corporations the lead over their European counterparts because Europeans believed you needed a good product before you could sell it. That was quite naive. Long before their product was good enough, the Americans owned the market and had the budget to make it better than the European product. In this way, Americans discarded failed products without investing much in them, saving costs. So, Oracle RAC on VAX VMS was not a great idea because RAC was in its infancy. At the same time, VMS was an exotic operating system with few customers, making fixing RAC bugs on VAX VMS a low priority for Oracle.

Not surprisingly, the system regularly malfunctioned, preventing users from accessing it. RAC is a cluster of machines accessing the same database. The idea behind RAC was that if one of those machines crashed, the others would remain operational and the database would remain accessible. In reality, the machines often went down in unison because of communication errors caused by the RAC software. And because the whole point of Oracle RAC was to have less downtime, you could do better without it. The crash corrupted the machine’s memory, and looking for the cause was pointless because it was a bug in Oracle software for which there was no fix. The only thing we could do was reboot these machines, which meant shutting them down and restarting them. That would wipe the memory clean, and the system would work again. I figured that out after one time, so the next time, when the symptoms were the same, I didn’t hesitate. The system was critical. It had to be up always. That was why it was our only RAC system. Otherwise, the police might not identify criminals. It was a database with the records of criminals dubbed Reference Index Persons, and the Dutch acronym was VIP, so the Very Important Persons for the Department of Justice.

Bureaucrats often seem to value rules over outcomes, which made me wonder what they were thinking. It could be something like, ‘If I mess things up, no one can blame me if I stick to the rulebook. But if I do the right thing but do not follow procedure and something goes wrong, my job is on the line.’ If something goes wrong, the government hires consultants to investigate the issue and propose changes to the procedures to prevent it from happening again. Consultants thus write piles of reports and make a lot of money on government contracts. Sadly, the next time, the situation may be different, and then it goes wrong again. Over time, the proliferating rules grow unwieldy.

It might make you think it is better to do away with procedures, but that is not a good idea. The proliferation of rules reflects the increasing complexity of society. It is not a problem that you should see in isolation. When a large apartment building burns out, you see once again why there are strict building regulations concerning these skyscrapers. If you aim for fewer regulations, you build these things in the first place. The government’s task is to provide and enforce these rules. There may be room for improvement. It begins with not creating the problem that gave rise to the regulation. Our office processes traffic fines. If we stopped driving cars, most of our work would be redundant. And perhaps, we should give people more responsibilities, but that means accepting that things sometimes go wrong. The result may be that fewer things go wrong.

DBB not only joked with the bureaucrats, but also with me. In June 2010, I received a highly unusual request from a system administrator to manually drop a user account. That hadn’t happened for several years. DBB usually handled that, but it failed to drop this particular account for an unknown reason. The username was ELVELVEN. If you read that aloud, you say eleven elevens in Dutch, referencing the 11:11 time-prompt phenomenon that had once haunted me for a while. Usernames consisted of the first one or two characters of the employee’s first name, followed by the employee’s last name. In this case, the user’s last name was Velven. I don’t remember the first name, but it wasn’t Elvis. To me, 11:11 signals a combination of two related unlikely events. And indeed, the joke had a part two, and it was even more peculiar.

In 2014, during testing of an improvement to DBB, the test indicated that an unauthorised account had infiltrated our systems. The username was the first character of the first name, followed by the last name of the Lady from the Dormitory. Had She been employed by us, this would have been Her username. Her name isn’t common, so this was unnerving, especially since it was the only username that popped up in this list of sneakily inserted accounts. It couldn’t be Her, or could it? It turned out that a guy with the same last name as Hers had worked for us. His first name began with an A as well. And the account wasn’t illegal. I had mixed data from two different dates in the test, which made it appear that this account had sneaked in illegally. But imagine the odds of only this account popping up on that list.

In 2005, after completing DBB, my manager wanted to give me a promotion, and he only wanted to give it to me. My colleague Kees was a tech genius, and he set up the RAC system while I made DBB, so I said he was better than me. My manager responded with the prophetic words, ‘You have the right vision and make it happen despite the opposition. That is far more important than technical skills.’ DBB solved pressing problems using proven technology, while the RAC system only created problems. We used to reduce system downtime, but it produced system crashes, resulting in more downtime. Somehow, I had become his favourite, and that wasn’t because he was such a good manager. He seemed the type of career guy who never stays long in one job. You know the type. He says he will clean up the mess his predecessor left behind and then hares off after a year or two towards his next challenge, claiming he has put things on track, only for the next manager to come in and claim he will clean up the mess.

He never put his promise in writing, despite my repeatedly requesting that he do so. Just before he left, I pressed him again. As the promotion had not yet come through, he wrote that there would only be a minor wage increase, then filed it with the human resources department for processing. A few weeks later, they summoned me to the human resources department. A personnel officer had raised a technicality. It wasn’t against the rules, but against their policies. And so, I couldn’t even keep the minor wage increase. That was a breach of contract, plain and simple, but to a bureaucrat like a personnel officer, only rules and procedures count. It would have been possible to fix this within the rules, but there was also a thing called policy, so they didn’t. My previous manager had already left, and they blamed him for not following proper procedure. His temporary replacement didn’t care, as he was also on his way to another job. After putting a lot of effort into getting it in writing and with my manager already fobbing me off with a minor wage increase, they gave me nothing. I was angry and walked out of the meeting.

After arriving home, my wife told me that a freelance agency had offered me a job. It was the first offer of this kind in years and the first time since working for the CJIB. I was already considering leaving. That made me make a rash decision and resign. In hindsight, it was a noteworthy coincidence that the freelance agency had called me on this particular day. It didn’t take long before I did get second thoughts. Out of the blue, a strong feeling emerged that the decision was wrong. I can rationalise it by saying there weren’t many jobs for database administrators near home. The issues with my son didn’t allow me to work far away from home, while my physical condition didn’t allow for long travels. That may all be true, but these considerations were not the real reason. And I had done freelance work before, so it was not fear of being self-employed. And a government job didn’t seem right for me. But the feeling grew so strong that there was no choice but to reverse course and try to undo my resignation.

Pride is a poor counsel, so I reversed course. There was a new manager, Geert, and he accepted my change of mind. He pledged to do his best to restore my confidence in my employer. He seemed trustworthy, but actions matter more than words. A year later, he promoted Kees, but not me. Due to a bureaucratic technicality, there was only one position. And perhaps also because Kees was his favourite. That didn’t restore my confidence, so I began to distrust him. Geert was still planning to promote me. He gave me financial compensation, so the situation didn’t result in a financial loss. And after several years of bureaucratic wrangling, the promotion finally came through.

Latest revision: 2 December 2025

It’s a miracle

In early 1993, I started to look for a job. My first application was for an IT traineeship at Cap Gemini. They had sixteen vacancies. Some 1,600 people applied, of which they selected 200 for a series of tests. I was one of them. Before these tests began, other applicants told stories about assessments and job interviews they had gone through. The economy fared poorly, so there weren’t a lot of jobs. Many graduates were already searching for a long time. It was discouraging, so I expected to remain unemployed for quite a while.

That was not meant to be. The tests went well, and they invited me for an interview and some more psychological tests. On my way to the appointment, a guy I knew from dormitory Witbreuksweg 389-2 came sitting on the opposite seat on the train. He asked me why I was wearing a suit. I told him about the interview. Then he started to laugh loudly. ‘Your tie is a mess,’ he said, ‘Let me fix it for you.’ He then arranged the tie correctly.

If this event, which appeared accidental at the time, hadn’t happened, they may not have hired me. The interview and the tests went well. My misfortune because of not fitting in during my student years made me investigate cultures and cultural differences. It wasn’t hard for me to translate the expectations of Cap Gemini concerning its employees into test answers. And so, the test results made it appear as if I fitted perfectly into the corporate culture of Cap Gemini. Cap Gemini stressed I was the master of my own destiny. It was one of their company slogans.

They hired me and sent me to a junior programming class to prepare for my first assignment. My self-confidence was low as I had manipulated the test. Perhaps, I didn’t fit in. And it was shortly after the encounter with Suzanne. I was afraid to turn up because I felt unfit for the job. These feelings receded once the class had started. We learned about programming. I was often joking about a programme I was planning to write. I nicknamed it DoEverything as it was supposed to do everything, which is noteworthy because we may be part of such a programme.

My classmates often discussed what car they would choose once they were on the job. I was the only one planning to use public transport. Not surprisingly, I was not a model employee. One classmate, a cheerful guy from the Eindhoven area named Ad, expressed his amazement about the fact that I passed all the tests. ‘There were 1,600 applicants. And they picked you? It’s a miracle! How could that happen?’ Ad and I had a good laugh about it. His last name referred to Burgundy. In the Netherlands, a Burgundian lifestyle denotes enjoyment of life and good food, most often found in the vicinity of Eindhoven. And Ad radiated this lifestyle. He seemed the personification of it. His first name and the region he came from make another peculiar coincidence in light of later developments.

With regard to the work that awaits us

My first assignment was on a project at the Groningen office of Cap Gemini. I became part of a team of six with a few colourful personalities. Our customer had hired us but didn’t come up with work. For months we had nothing to do, but we had a lot of fun. And I had more fun than I ever had during my student years. Our project manager was ambitious. He organised project meetings and demanded progress reports he could present to senior management even though we did nothing. One of us was a graduated linguist, so he used his skills to produce eloquently written progress reports. For instance, he wrote, ‘With regard to the work that awaits us, we can only assume a wait-and-see attitude.’

Another guy was a hippie and had been part of the squatters’ movement. He always wore the same orange sweater. Perhaps, he had two orange sweaters, but I am not sure. He was the type of guy who might wear the same sweater for months. He often made fun of the project leader and his ambitions. At the time, Windows was gradually becoming the standard operating system. It had new features like WAF files for sounds. Some team members played around with these features, so if I started my computer, it sometimes made an unexpected noise. I had so much time on my hands that I familiarised myself with database administration. After a few months, the work came in, so the project manager was busy managing our work. He constantly demanded progress updates.

We soon realised we would miss our deadline at the end of July. Before the project manager went on a holiday, he discussed the situation with our customer and arranged a new deadline date at the end of August. Once he was gone, things suddenly went smoothly, so we met the original deadline date in July, possibly because the project manager stopped managing us. When he returned, the programmes were already running at the customer’s site. His superiors praised him for delivering a month ahead of schedule. He was on his way to a great career. Perhaps he received a bonus too.

There is room for improvement

The next job was restructuring a database at a telecommunications company. I had some database knowledge. And my managers were impressed that I had familiarised myself with database administration. And so, I did get that job. The company doubted the capabilities of their database administrator, so they hired me to reorganise one of their databases. They took this delicate task out of the hands of their own database administrator and gave it to me, a novice with little experience. And so, their database administrator didn’t like me from the start. And I didn’t follow his advice because he was a bungler. After all, that was the reason they hired me. And he was showing off his expertise by using incomprehensible language, so I often had no clue what he was talking about.

It was a highly political environment. The telecommunications company had been a government operation for a long time, but the government had just privatised it and put its shares on the stock market. The board wanted to purge the old-fashioned government bureaucrats from management positions. And the department I worked for was led by a risk-averse bureaucrat fearing for his job. If something went wrong, his head might roll. And the database administrator might have felt that his position was on the line too. He often complained about me to his manager. And the manager passed on these complaints to Cap Gemini. I also had a team leader who knew the situation and gave a more accurate depiction of what I was doing to his manager and my account manager. That is why they didn’t take me off the job.

And I caused a major accident. To reorganise the database, I needed a list of the tables in the production database and their sizes. Production is the database that matters. The data in the production database is precious. For that reason, I had no access to the production database. There are also databases for development and testing. But I needed production data, so I prepared a file named tablelist.sql containing a query that delivered the necessary data. And for once, they allowed me to access the production database using a tool called SQL Plus. I could start the script by typing @tablelist and pressing enter. I started typing @t. The system didn’t respond, so I pressed enter to see if there was any response at all. And then, I saw the system respond with table dropped, table dropped, table dropped. I cancelled it, but it was already too late. Some precious data was already gone. The operators restored a backup of the previous night, so a day’s work was lost. The database administrator had left a file named t.sql in the SQL Plus directory, dropping all the tables. It was an accident waiting to happen. And even though everyone knew that, the incident reflected poorly on me. With the benefit of hindsight, it was odd. How much bad luck can you have?

Because of the fuss, Cap Gemini sent me to a course called Professional Skills. I was not politically sensitive, and that could be a handicap when you work at the site of a customer. I was aware of that as I had a way of formulating things clearly, so I considered it a good idea. And the course taught me something. For instance, positive framing can contribute to a better atmosphere. You can call it political correctness. So if it is a complete mess, you can say, ‘There is room for improvement.’ Even though it is the same mess, it sounds a lot better. After all, a consultant’s primary responsibility is not to solve problems but to make money for Cap Gemini by making the customer happy. I let it all pass by, concentrated on my task and successfully finished the database restructuring job.

My next assignment was at the real estate department of the telecommunications company. They hired me to make database queries in their financial system for management information. Usually, managers or salespeople wanted a report promptly. It was always very important and, of course, very urgent. I called them jokingly life-and-death queries. It took a few hours to write a query, check the validity of the output, and deliver the report. By then, it often wasn’t needed anymore. The availability of the data rather than necessity created a demand for these reports. In other words, the reporting usually wasn’t that important. Over time, I found patterns in their requests, so I made a set of standard queries with parameters and delivered 90% of the reports on the spot. No one had ever thought of that, so they saw me as a genius and hired me for a longer time to work on their systems.

Hit the moving target

Cap Gemini emphasised the concept of employability. You were responsible for your employment by ensuring your skills were in demand. ‘Hit the moving target,’ is what they called it, referring to the constantly changing market for skills. You must be there where the demand for skills is. During a company meeting, they once gave us toy guns to aim at moving targets on a large projection screen in the front of the room.

Times were changing, and I had been working on the obsolete systems of the real estate department for a few years. My manager and I agreed I had to catch up with the latest developments. In 1995 and 1996, two new development tools, Oracle Developer/2000 and Designer/2000, came to the market. And so, they sent me far away from home, to Zeist, where Cap Gemini had started an Oracle Developer/2000 software factory, a marketing term for a group of people working with Oracle Developer/2000. Zeist was far from home, so I stayed in a hotel nearby. The newest tool was Oracle Designer/2000, and Oracle introduced it when I worked at the software factory. It had a promising future. Designer/2000 could generate Developer/2000 programmes, so you didn’t need to write them yourself. I gained experience with Developer/2000 and also Designer/2000. After a year, I hoped for a Designer/2000 assignment near home.

My manager agreed, but there was trouble brewing once again. An account manager came up with a prospective assignment. I knew him. He was a rough guy who only cared about his bonus. People like him might have done well in the Wild West, playing poker, staring down opponents and engaging in brawls in saloons. I told him that I specifically aimed for a Designer/2000 assignment as I had invested much time and effort in Designer/2000. He said, ‘The customer is planning to switch to Designer/2000, and you can play a role in that process.’ He didn’t disclose any additional information. His vagueness put me on high alert, and I presumed he was planning to dupe me. And so, I warned him that I would decline the job if it wasn’t Designer/2000.

I contacted my manager and discussed the situation with him. I had invested much time in Developer/2000 and Designer/2000 and had been away from home for a year. I would rather stay away from home a few months more if needed to get a proper Designer/2000 assignment. Designer/2000 was just released, so work had yet to come in. If you intend to hit a moving target, you must aim just in front of it, considering the direction of the movement. It takes time for the bullet to arrive at the target. By then, the target had already moved a bit further. So, I was already there, where the target would soon be. And there was plenty of work at the software factory. And so, I asked him if I could decline the job if it wasn’t Designer/2000. He said that sales targets were important and we all must do our bit. But I was supposed to be the master of my own destiny. Knowing that my Designer/2000 skills would soon be in high demand, I said I would look for another employer if that would be his stance. He then gave in.

But the account manager pressed on, ready to make the kill. Before the interview with the customer, another department of the telecommunications company, we once more discussed the assignment. And again, he didn’t say much more than, ‘They are planning to switch to Designer/2000, and you can play a role in that process.’ Once more, I warned him in no uncertain terms. And despite his name being Warner, he didn’t appear to understand what a warning was. Still, his name was endowed with a whiff of coincidence. Then came the interview. The department manager told me they planned to use Designer/2000, but their people would do the Designer/2000 work. They needed me to maintain their obsolete systems. And my resume was perfect as I had been looking after the old programmes of their real estate department for a long time. That was the role I could play in the process. And the account manager knew that all along.

Assuming that the account manager was ready to close the deal and seal my fate, I declined and said I wasn’t informed about the nature of the assignment. And so, I humiliated the account manager in front of the customer and made Cap Gemini lose face. The account manager probably had believed he could get away with it. Indeed, I didn’t want to cause a fuss again, but I thought Designer/2000 to be crucial for my future employment. After all, life is a bitch. If you end up with obsolete skills, you end up unemployed. A few weeks later, I did get a Designer/2000 assignment in Groningen, so close to home that I could bike to work again. Later, my manager said that my actions were unprecedented and had raised several eyebrows. On closer inspection, I could have been a model employee, and more than Cap Gemini might have hoped for.

Walking out of Paradise, once again

After moving to Sneek, I looked for a job near home. There was a vacancy for a software designer at FBTO, an insurer in Leeuwarden. It later turned out that the job included being a project leader. The insurer had split the IT department into smaller teams working for a business unit. Every three weeks, we planned our tasks for the coming three weeks, and a business unit representative determined the priorities. It worked well as we had fewer political games, like business units competing for resources. The IT department was well organised compared to what I had seen elsewhere. This way of running IT departments has become commonplace two decades later.

The team knew what they were doing, so I felt redundant as a project leader. There is no point in managing people who know what to do. The atmosphere was friendly. I had grown accustomed to grim conditions, so I felt out of place. I could have gotten used to the friendliness but not the job itself. All those documents, meetings, and priorities were boring. Building information systems was much more fun. I was qualified for Oracle, but FBTO didn’t use Oracle. I decided to try my luck as a freelance Oracle Designer/2000 developer and database administrator. And so, I walked out of Paradise again, but this time out of my own will. After all, Cap Gemini had taught me that I was the master of my own destiny. But an ominous incident would soon suggest that I was not.

Latest revision: 7 January 2023

Featured image: Cap Gemini logo