Founder's Story

Lars Kruse - Founder:

The story of how Mind over Machine came to be is best told by describing the things I did before it. Mind over Machine is an attempt to gather up everything that worked and avoid everything that didn’t. It is a kind of meta-summary of my career, in which I have tried to build companies that were different from traditional tech companies, and where I focused on creating value for users, employees, and society as a whole — from my position in the tech industry.

It is a journey filled with both successes and failures, and one that has shaped my vision for what Mind over Machine should be today.

I founded Praqma in 2007, after having worked in tech consultancy for about 10 years at that point.

I was frustrated by watching how software was built and delivered in many organisations. It was slow, risky, and in many ways a monotonous Sisyphean task for the people carrying it out. The people I knew who really burned with passion for making software were often engaged in Open Source projects in their spare time, simply because their day jobs were not ambitious or satisfying enough. I thought there had to be a better way to harness all that potential.

This was pre-agile. From my education as a computer scientist, I had studied Participatory Design and lean principles — user participation. I always had a particular interest in automation and Continuous Improvement, and in that way I was steered early in my career toward what we today broadly call the Software Development Lifecycle (SDLC).

At the same time, I was indignant about how many tech companies — particularly consultancies — exploited their employees to build relatively large profits. I saw that most companies have no real mission. There was no greater purpose beyond making money for the owners, usually without the employees getting any share of that profit. I wanted to create a company that was different — a company that put people and purpose first, not profit.

Together with a friend and one of that friend’s acquaintances, I started Praqma. We had no business plan, no investors, and no clients beyond those I had worked for as a freelancer from 2001 to 2007. We called ourselves Praqma, as a direct reference to our pragmatic approach to software development. We wanted to contribute to making it simple to create software. Our vision was expressed in a few opening statements:

— We want to make the world a better place — at least the world of software
— We want to create a company that we ourselves would want to work for

All three founders at Praqma were computer scientists, but at the time I was the only one in the group with concrete experience of building software for what we might call “the ecosystem around software development” — tools, processes, and methods for building and delivering software. The others had concrete experience writing the product software itself. But we all agreed that was the area we wanted to focus on. We thought we saw a trend and believed it would become big.

With that assumption, we hit the mark. Git had just been invented, #DevOps emerged as a Twitter hashtag in 2008, GitHub launched the same year. Duvall and Matyas published “Continuous Integration” in 2007. Humble and Farley wrote “Continuous Delivery” in 2010. Conceptually, we were ahead of the entire movement that within just a few years would transform the entire discipline of software development at its core. In hindsight, we genuinely earned significant recognition in that community. But in reality, in our early years we were truly bad at running a business.

We had no business model. One partner dropped out within a year. The financial crisis exploded in our faces. From 2007 to 2014 we had a total of only 8 employees — we could not grow and were in a constant fight to survive. In 2014 we had the revelation that we needed to focus on building a strong brand and a strong culture. We began actively cultivating the community we were passionate about, through blog posts, open source projects, conferences, events, and pro-bono teaching at universities and other educational institutions.

From 2015 to 2018 we held more than 150 conferences and meetups across Scandinavia, and we founded CoDe Conf — CoDe standing for Continuous Delivery — as a standalone brand. Later we also founded the Danish chapter of DevOpsDays, a worldwide non-profit umbrella organisation that runs an annual two-day conference for the DevOps community in virtually every imaginable city in the world. We ran the Danish chapters in Copenhagen and Aarhus, and our Oslo office helped start a chapter there.

We had a successful internship programme, through which over time we ended up hosting more than 40 students who participated in our various Open Source projects. A handful of them were eventually hired as full employees.

We also established a CoDe Academy, where we offered three days of free intensive teaching as a summer school for students on software programmes. We taught Git, Docker, Jenkins, and Scrum — the things we believed that generation needed to learn but which were not taught at universities. We got our clients to sponsor parts of it and covered the rest of the costs ourselves. It was a huge success and we ended up running the programme in Copenhagen, Aarhus, Gothenburg, and Oslo. We put over 400 students through the programme over time.

We created an Open Source consortium, JOSRA: Joint Open Source Roadmap Alliance — an alliance of companies that dedicated time and resources to understanding each other’s challenges, looking for common generic solutions, and then paying Praqma to develop Open Source products that benefited everyone in the alliance. We had Grundfos, Volvo, Yxlon International, MAN Diesel & Turbo, Microchip, and several other large Scandinavian companies in the alliance. It was a fantastic way to fund Open Source development. There was not much money in it for us at Praqma, but the karma, goodwill, and trust we built up was enormous.

For long stretches we spent more time building the community and generating knowledge and content than running the business. In many ways Praqma was a think-tank rather than a consultancy.

The strategy was a huge success. We built a fantastic reputation in the industry, which led us to attract the best talent and the most exciting clients — who were just as ambitious as we were. Our employee churn was very close to zero.

From 2015 to 2018 we grew from 8 people to roughly 50 employees and established offices in Denmark, Norway, and Sweden. Throughout that entire time we were self-financed, with no income beyond our consultancy and teaching activities. We had grown into a healthy business; our turnover was on a par with other tech consultancies. But all our profit went into financing our growth. In 11 years we never paid a dividend out of Praqma once. On the contrary, there were long periods during which my co-founder and I had large personal loans into Praqma, and even long stretches of significant wage restraint among the owners to keep everything running.

Cracks began to appear in the solidarity. Initially relatively minor disagreements about the business model and professional direction — particularly different views on the obvious problem that our earnings were too low. An internal pressure emerged simply to make money, wherever it came from.

Our visibility in the industry had opened an opportunity to become a reseller and even a Platinum Partner with a very central supplier of proprietary license-based tools tailored precisely for the SDLC. An opportunity arose to earn a lot of money selling their products, teaching their courses, certifying our consultants in their programmes, and selling consulting hours on the back of that partnership.

The sacrifices we would have to make were to drop our otherwise fundamental principles of being tool-agnostic, of keeping focus on Open Source, and of scaling back our long-term system thinking strategy in favour of a focus on making money in the short term.

This grew into major internal battles, and it became clear that among a majority of the owners the mood was shifting toward leaving our mission statement about making the world of software a better place behind. To shift from explore to exploit, to start paying proper senior executive salaries. As in a failed marriage, things were said that you cannot come back from, and a divorce was inevitable. But in a company of that size, where more than 85% of the shares sat equally distributed between two people — who were now separating — it was impossible to raise the money for either of us to buy the other out.

We made an attempt to give our employees a voice and worked for a brief period on a programme to sell the company to our senior employees, but in that process we became even more at odds, now over pricing. So we went to market and found a buyer.

It was one who was interested in our standing in Scandinavia, our employees, our clients, our business, our turnover, and our newly acquired Platinum Partner status. But who had no particular interest in our culture, our brand, our community, our conferences, our CoDe Academy, our internship programme, or our Open Source activities. Our buyer was on a buy-to-sell mission — acquiring companies like ours, optimizing them for profit, and selling them on again.

From the perspective that we were in a hurry to separate, it was not a bad buyer. But it was not the right buyer for Praqma. Praqma changed its name the day I left the company. And the moment all parties had completed their earn-out, they were out. The majority of our primary activities were immediately put on ice, and all former Praqmates were now employees — of an entirely different company.

I threw myself into another venture: Prolike. Again without investors and without a written business plan. The ideas were fundamentally the same, but this time the focus was on the internship programme we had built at Praqma, and I was determined that the company should have a community at its centre from day one. Within didactics and problem-based learning there is a concept — Community of Practice — which among other things aims to enable Legitimate Peripheral Participation. That was precisely what I was trying to build.

Prolike was named that way because all our employees were novices or learners — “like a pro.” We grew quickly to about 8–10 employees, all of whom were either newly graduated, still studying, or dropouts from tech programmes.

We called ourselves an apprenticeship IT company. Our focus was on SaaS products on serverless infrastructure. We were on the scent. We didn’t make a lot of money, but just enough for me to personally keep my hand under the operations and payroll. We had a culture in which everyone was involved in everything — sales, marketing, bookkeeping, development, infrastructure, operations, support. It was chaotic mess, but a very vibrant workshop for problem-based learning.

Then COVID came and it became impossible to run a company that way. Two days after the prime minister’s press conference we had received notice from all our clients that they were stopping their activities immediately. We had no capital to survive without income, so we had to close. I did not even have the money to pay three months’ salary to all employees under normal notice terms, so with a remarkably large degree of engagement and empathy from all employees we made it work. A handful chose to return to university. A handful we placed as permanent employees at the companies we had been working for. A couple found other jobs themselves and a couple took over a contract as freelancers on the client they had been working with.

In less than a month, Prolike had been emptied of employees, clients, and projects.

I had never been employed by Prolike myself. In parallel I had founded inc inc as my own advisory business for my personal activities. Inc inc comes from “incorporated incorporated” — a company that helps companies. At around the same time we closed Prolike I brought a partner into inc inc — one of my former colleagues from Praqma, who had originally joined us as an intern. We scouted for pre-seed startups with ambitious and complex IT tasks that were more than they could handle themselves. Our intention was to come in as co-owners, establish their IT and software infrastructure, and help them grow.

We interviewed more than 40 startups that were in the target group at that stage. We helped a small handful get their infrastructure and development processes in order, but there was something about our approach that was cut wrong. Startups were happy to have our help, particularly in the initial phase, but they were not interested in having us as partners or co-owners. Generally we experienced that startups in the pre-seed phase are excessively protective of their not-yet-existent business and not ready to share ownership with more hands in exchange for help succeeding. Startups dream of cash injections.

Of all the startups we were in contact with through inc inc, I know of only two that still exist today. The vast majority of them never created the IT and software we offered to develop in exchange for nothing more than co-ownership. A paradox we could not break. It was an important lesson. We could not build an incubator company that way.

After that realisation it was not a difficult decision: my partner and I chose to close inc inc ourselves.

Shortly afterwards I was contacted by a friend who served as head of education at a Copenhagen business academy. He had a challenge that he believed I could solve. He was struggling with the political decision that the business academies were no longer allowed to run their teaching in English. Politically, a majority had wanted to prevent “education migrants” from the rest of the EU from coming to Denmark, receiving free education, and then going home again. But because of freedom of movement you cannot deny EU citizens from coming here. So the coalition parties had in their wisdom invented the trick of banning English-language teaching at business academies. This would supposedly save Danish society 150 million kroner in student grants by de facto stopping the flow specifically to business academies without formally breaching EU obligations.

For the business academies, the unintended consequence was that they were cut off from their established international exchange programmes with other schools. These programmes almost all operate on a quid-pro-quo basis. Now they could no longer send their own students out into Europe, simply because they could no longer receive students from Europe. It was a disaster that hit every field of study and which no one in the political debate had foreseen — but which the business academies were now left to find a solution to themselves.

My friend had found a realistic loophole in the legislation. The ban on English-language teaching applied only to full programmes. It was still possible to run individual elective modules in English. The idea was therefore to create a brand-new elective module, a full 30 ECTS, taught in English, with content as broadly interdisciplinary as possible. The ambition was to be able to enrol students from design, STEM, and business development programmes on the same curriculum, so that just one module at the business academy could unlock all the collaboration agreements that had been closed off.

My task was to assemble and lead the working group that would invent this module, plan its content, write the study programme, and execute the first semester. — I accepted the challenge.

Together with colleagues we developed the module “Digital Product Development.” I ended up being at the business academy for a total of three semesters. The first went into planning, the second into offering it to international partner programmes and recruiting a cohort of students, and the third into executing the first run with a group of about 30 students. The second semester was a somewhat transitional period for the elective module itself, so during that time I taught on the computer science programme and the IT architecture programme — the same things we had focused on in CoDe Academy, that is, concepts the established programmes often don’t cover: DevOps, Continuous Delivery, test automation, lean software development, and containerization.

The execution of the elective module became yet another instructive experience in establishing a Community of Practice. The students were connected to various companies for whom they would concept-develop and pre-test ideas, using user involvement, no-code tools, and mock-ups.

My position at the business academy was time-limited from the start. When it ended I was offered the opportunity to continue in an assistant lecturer track, but I did not see my future in a operational role as a permanent teacher at a teaching factory, so it was time to seek new adventures again.

That became a period of two years with The Tech Collective.

The Tech Collective is a group of otherwise unrelated subsidiaries, all owned at a minimum of 75% by Implement Consulting Group. Implement works in management consulting but wanted to establish a tech consultancy business. They had run into a couple of concrete challenges: partly the paradox that Implement fundamentally found the hourly rates for tech development uninteresting relative to their management consulting rates. Moreover, there was an internal culture at Implement expressed in their tagline “The best place for the best people” — concretely manifested in the inviolable principle that a master’s degree is required to be hired at Implement. And it would be an unnatural constraint to impose on oneself in the tech consultancy industry, where it is more common to hire people with a wide range of backgrounds and experience, and where having a master’s degree is not necessarily a requirement for being good at making software.

Establishing an independent brand, “The Tech Collective,” as an umbrella for an undergrowth of subsidiaries solved both challenges at once, while still allowing Implement to maintain control and a fixed supplier relationship to the parent company. One of these subsidiaries was a consultancy that had chosen the name “Test and DevOps,” but which after about two years of operation still had not a single DevOps service to offer. All services were based on test management.

I was brought into Test & DevOps as a business developer with the aim of establishing a DevOps business to supplement the test management. The two partners knew my history with Praqma and my mandate was essentially to build Praqma 2.0 as an independent business inside Test & DevOps. I was promised a partnership — and thus co-ownership — and would have free rein.

My own reasoning was that I would love to do it again, to stand on the shoulders of Praqma, Prolike, inc inc, and my experience of building Communities of Practice. I was assured there would be ample funding for the establishment phase and that the otherwise very strict earnings targets Test & DevOps had inherited from Implement would be relaxed during that period. In other words, the preconditions for long-term system thinking should be in place. And I would not need to put my own money in. On paper it looked like a perfect match.

Initially things went well — establishing a small team, some sporadic business, and a lot of outward-facing activity to build a brand and a market position.

After barely six months there was a declared shift in Implement’s focus and control over The Tech Collective. It was made clear that neither The Tech Collective nor Test & DevOps for that matter would act as an independent brand; instead, all The Tech Collective companies were to act increasingly as departments under Implement. We were asked to wind down our outward-facing activities and focus on hitting the earnings targets Test & DevOps had inherited from Implement.

In hindsight, that was probably my cue to leave the project, but at that point we had already taken on some concrete assignments, so it was natural to shift focus from building a brand to building a team. Over a period of nine months we established a team of about 10 employees — a mix of former Test & DevOps employees from the testing activities and a total of seven new hires with developer and DevOps profiles whom I had recruited.

Despite our success in building the team, we were under constant pressure to deliver on the earnings targets Test & DevOps had inherited from Implement. It was something of a paradox, because our largest client was a major Implement project in which we were a subcontractor on a large implementation task. This was not an assignment particularly suited to building a DevOps business. It was a classic waterfall project in which we were asked to estimate and deliver a fixed-scope, fixed-price task. It was simply not possible to deliver at the price Implement had sold us for — and we spent time re-estimating, negotiating, and explaining, only to miss our targets and then re-estimate, negotiate, and explain again.

It was a frustrating period. Despite everyone working overtime, we had a hiring freeze — until our earnings figures improved.

My assessment was that we needed to establish other business and work for clients who thought more like ourselves and where we could deliver on our own terms — building quality into the product rather than having to deliver against a fixed-scope, fixed-price contract where the only lever we had was to downgrade quality and accept technical debt.

We even had a small handful of exciting assignments in the pipeline that were genuinely the kind of work we wanted to do. And I started part of the team on those. But the hiring freeze meant that capacity was being pulled from the Implement subcontracting assignment — which was already bleeding. The Implement partners responded by opening a dialogue with the Test & DevOps partners about whether I could be allowed to pull resources from that assignment and into other work.

It was clear there was no match between Praqma 2.0 and Implement’s new tight control over The Tech Collective. I fell into bad standing with the Implement partners, and the Test & DevOps partners began distancing themselves from me and from our original vision of building a DevOps business. The premises had changed, and it was time for something that could not fly with me at the wheel, so I went looking for new adventures again.

During my time in Test & DevOps we had developed a handful of Open Source projects, which we had originally built simply to support our own flow — which was based on a very ambitious degree of automation. We had also almost immediately after Agentic AI was released thrown ourselves into experimenting with using it actively in our daily work.

These projects and experiments were part of our long-term strategy and contributed only indirectly to our earnings. Since they generated no visible income, they had been partially put on pause as Implement’s patience with us steadily declined. Nevertheless, we had many concrete wishes for continuing to develop them, and we were confident that over time we would find a way to present them as an asset to our like-minded clients, and thereby use them to differentiate ourselves in the market and build a trust-based relationship with our clients.

In the time after The Tech Collective, I spent all my time further developing and maturing these projects and experiments. It was a fantastic way to hold on to my vision and my position, while working on something I genuinely burned for, without having to worry about short-term earnings. I wrote blog posts about my results and ideas, I held free workshops and events for whoever wanted to listen, and through that I received a great many enquiries from people I entered into dialogue with and met.

I became a living example of one of my own earliest observations in the industry: that people who truly burn with passion for making software are often engaged in Open Source projects alongside their jobs.

During that same period — the time immediately after The Tech Collective — it was also the season for organising the annual DevOpsDays conference in Copenhagen. I still sit on the board and in the organiser team for DevOpsDays Denmark. It is a fantastic way to stay in touch with the industry, meet new people, and share ideas and experiences. It is also a way of giving back to the community that has given me so much over the years. I used all my newly developed tools and concepts within DevX and Agentic AI to build a concrete product — a long-awaited new conference platform for DevOpsDays Denmark.

But the world turned out to be entirely new and different. Despite a true abundance of speaker proposals, a comprehensive programme for both days of the conference, and more sponsors than we are used to seeing — with several approaching us completely unsolicited — our otherwise very popular conference could not sell more than 8 (eight) tickets after the first 30 days.

It was a huge eye-opener for us. At the same time we see that DevOpsDays in Amsterdam also has to cancel, and in Washington DC the organisation has changed its entire charter and disassociated from the DevOpsDays umbrella organisation, because DevOps no longer sells tickets. We have conducted various surveys among more than 550 former conference attendees and on social media, and rather than DevOps being dead or dying, it is probably more accurate to say it has gone mainstream.

Several people we have heard from suggest it has transformed into the discipline known as Platform Engineering — but that is a classic Ops — that is, infrastructure — discipline that does not involve Dev, meaning developers. In its early years DevOps stood for a socio-technical discourse that also gave birth to a DevX — Developer Experience trend — and that advocated breaking down silos in the work. A clear reference to Conway’s Law and an invitation to a holistic view of the entire development process, including a focus on developer burnout and transformational leadership.

If it is true that DevOps has transformed into Platform Engineering, then it has become a discipline increasingly focused on optimizing infrastructure and operations. It has no social or cultural focus, and it has no focus on developers.

In DevOpsDays Denmark we have decided that, like our sister organisation in Washington DC, we too would change our charter and disassociate ourselves from the DevOpsDays umbrella organisation. We will no longer call ourselves DevOpsDays. Instead we will keep our focus on precisely that socio-technical agenda and maintain focus on supporting a community — whatever it ends up being called — and try to seek answers to “what on earth is happening in tech right now.” Not through an annual conference, but through a broad range of different activities, events, and initiatives that can help us contribute to ensuring that the software industry continues to have an agenda in which people are factored in.

The seed of “Mind over Machine” is sown at that board meeting in DevOpsDays Denmark where I propose scaling up the ambition and perhaps establishing a genuine think-tank — not just an association. I envisioned Praqma 2.0 again, but this time with a dedicated non-profit purpose, our vision and mission written into the bylaws. Administered and governed by a general assembly, a board, a secretariat, and a full Community of Practice.

It was an idea received with enthusiasm and support — even though everyone agreed it would stand or fall with me running with the baton and making it happen, since everyone else on the board and organiser team is fully occupied running their own companies and projects.

The name “Mind over Machine” is a reference to Hubert and Stuart Dreyfus’s famous model of skill acquisition, published in a book entitled precisely “Mind over Machine.” The Dreyfus brothers are attributed to belonging to the scientific discipline called “Cognitive Science” — a pre-AI discipline that is a mash-up of various socio-psycho-techno-anthropological orientations, and that from the 1950s all the way to today has set itself the task of trying to define precisely what intelligence is — partly with the purpose of contributing to the creation of artificial intelligence.

It thus follows implicitly that “Mind over Machine” has a focus that encompasses an AI agenda. At a high level it is again about making the world a better place — at least the world of software. It is therefore not some kind of back-to-roots anti-tech or anti-AI agenda. Quite the opposite. It is precisely about embracing tech and to a very great extent particularly AI — but with the perspective that we should use it to make the world of software better. For users, developers, society — yes, the whole planet.

In other words: “Regenerative Software Development.”