About on Jakob Wolman

Changing my tires - a Lean story

Mon, 27 Apr 2026 00:00:00 +0000

In Denmark there is a law stating: when roads are slippery your car has to drive on winter tires. This law came into effect in 2025, but practically most people have changed tires for the winter season anyway. A similar law has been in effect in Sweden for ages. Every year it is the same story. By the first sign of frost, people rush to get their tires changed. Once spring comes, people rush to get them changed back. Demand peaks, and when the peak happens depends on weather - hence unpredictable. Close to where I live there are two tire shops. One is part of a larger chain that also sells auto parts, bikes, and other things. The other is a small, local, independent shop that only sells tires, rims, and service. The chain has a booking system, the independent shop only offers drive in.

Do we need version control?

Wed, 22 Apr 2026 00:00:00 +0000

I have worked with software development for more than two decades. During that time, it has been an unchallenged truth that we need version control. Although CVS was notoriously fragile, SVN was frustrating and git was unintuitive, we never challenged the notion of making sure every change of the code was properly recorded. We were always ready to roll back versions that created problems and blame poor developers. AI assisted software development challenges the foundation of version control, and I’m starting to think if they are still relevant, and worth the hassle. Since software is becoming cheap and fast to create, we should get rid of the notion of going back in the recorded history. The only way is forward. If you find a problem in your code, even a critical issue, it is usually quicker to have an AI fix the problem and deploy the new code, rather than roll back to a previously working version. As I am an avid believer in trunk based development there should be a single truth of the software we are building. This should also be the software that runs in production. I am going out on a limb and claiming that branches, tags, releases, and other supporting functions have enabled us to create an overly complicated software life cycle. AI allows us to simplify this whole process. But beware, you still need good engineering practices to pull this off.

Who gets the benefits from AI

Wed, 25 Mar 2026 00:00:00 +0000

AI comes with a promise of increased productivity. There are wild claims about individuals now being 10 or even 100 times more productive because they are using AI. At an organizational level we seldom see these type of wild claims, and data shows that increase in productivity thanks to AI are much smaller, perhaps even as small as 10 % . That said, assuming that an individual can be 10 times more productive (without opening the can of worm of defining productivity), who benefits from these new superhuman abilities?

My own website

Sat, 14 Mar 2026 00:00:00 +0000

I have changed my mind. At least for now.

I am used to signing up for all kinds of services. My mantra has been to use what others have created. As a student I had plenty of time to fiddle with things, but as time became a scarcer resource I entered the I-just-want-it-to-work camp. I still like fiddling, but not with things that have to be maintained over time.

Leadership lessons from the scouts

Mon, 02 Mar 2026 10:10:49 +0000

Poster by artistHuskMitNavnfor Det Danske Spejderkorps

I’m a scout.

It is part of my identity, and it has been a constant during most of my life. Scouting teaches you a lot, but people who have not been part of the movement have a hard time appreciating the real value of the lessons. When you see kids tying knots and making fire, what they are actually learning is life skills, collaboration, and strong values.

The art of process knowledge

Thu, 12 Feb 2026 15:47:56 +0000

The Ise Jingu is a complex of Shinto shrines close to the city of Ise in Japan. Parts of the complex are over 2000 years old, but still built of materials like wood and silvergrass. Every 20 years, a ceremony takes place to rebuild the Shogu, the divine palace. It is rebuilt as a replica of the current palace, on a site adjacent to the current one. The ceremony, called Shikinen Sengu, takes around eight years to complete and includes everything from cutting new timber, transporting it, and constructing the palace. The first ceremony was conducted in the year 690, and the latest in 2013.

Empire of AI — a book review

Tue, 07 Oct 2025 06:08:13 +0000

I recently finished the book Empire of AI — Inside The Reckless Race For Total Domination by Karen Hao. Here are my notes and thoughts. And the broader question — is AI worth the cost and the risks?

In an age where AI development is moving at a breakneck speed and many AI companies are wielding unchecked power and unprecedented investments, the work of a journalist like Hao becomes very important. We are used to our elected representatives being scrutinized, but this is far from true for big tech executives who potentially hold more power and manage bigger funds.

Consulting is different

Wed, 27 Aug 2025 05:54:23 +0000

Developing software as a consultancy is different from what most product companies experience. Tradeoffs, costs, revenue, and decisions are different. Still, little writing and discussion exist about how we, as consultants, can improve and challenge the status quo of software development as a third party in today’s world.

When reading articles and books about organizational design, software architecture, and teamwork, I often reflect on how to apply what I have learned to my consulting organization.

Introducing friction

Mon, 24 Feb 2025 07:47:04 +0000

When things are too easy, it is no fun, coding with an AI included.

Have you ever tried playing a computer game that was way too easy, lay a jigsaw puzzle in five minutes, or had an AI write your email? It is easy, and satisfying to complete a task so quickly. But in the long run, it makes the whole endeavor boring. There is no challenge, no learning, and it requires little skills.

Reflections from cphdevfest 24

Thu, 12 Sep 2024 11:31:56 +0000

Attending cphdevfest was a blast. Here are a few of my takeaways, and recommendations of sessions you shouldn’t miss.

I’ve learned that an enthusiastic consultant who has just returned from a conference is one of the most dangerous things for a software project. Inspired they will pull out the old, boring, reliable enterprise framework the whole application is built on, and replace it with an exciting new technology, with new programming paradigms and a framework that has barely come out of alpha. Don’t be that person. Be inspired, and adapt the knowledge to your context.

Tools for assessing teams

Wed, 15 May 2024 07:33:39 +0000

How analyzing and understanding a team’s flow of work will help you ask better questions.

Disclaimer

Have you talked to them? That is always my first question when someone asks me how a team is doing. No matter the amount of data you have, nothing beats sitting down and talking to people. That is how you identify root causes and understand how to best help a team. Looking at data will not give you the answers. Instead, it will help you to formulate questions. As a system thinker, I see trends in data as signals in a system. They are something to be curious about, dig into, and understand better. But as with any data, you should not compare teams, or conclude directly from numbers on a dashboard.

What use is a manager?

Fri, 01 Mar 2024 07:57:57 +0000

I’ve been asked repeatedly by senior engineers — what use is a manager to me?

Skilled, senior engineers don’t need a manager, do they? Recently I’ve had conversations with staff-level engineers who claimed they have never had a manager that was of any use to them. They have had managers that did not understand what they were doing. They also expressed that they have had managers that thought they knew, and wanted to insert their own, somewhat incompetent, opinions into the work. At worst, they had managers that filled their day with tasks to do, and then expected frequent updates on the work.

Leadership is a skill

Fri, 23 Feb 2024 11:03:02 +0000

It is time we value leadership skills higher within tech and recognise that they can and should be trained.

–Do you code?

–I haven’t written any production code for about a decade, but I excel in leadership. Considering you are looking for a manager of managers, I assume there will be much more skilled engineers to write the code.

–Of course, but we are looking for someone who recently coded. Our CTO still submits code sometimes, and we believe it is a good practice.

Time management for mortals

Thu, 11 May 2023 11:44:07 +0000

Notes

These are my notes from following the course Time Management for Mortals, by Oliver Burkeman, on the Waking Up platform. I highly recommend everyone take this course and sign up for the service.

To get you started here is a conversation with Burkeman and Sam Harris in the form of a podcast.

The course is based on Burkeman’s book, Four Thousand Weeks which is a delightful read.

Facing finitude

Finitude means we are all finite, with finite resources. Time is finite, and our lives are finite. We choose how we spend our time.

Boring organizations are the best

Mon, 10 Jan 2022 16:40:32 +0000

We keep hearing stories about superhero developers, teams of rockstars, and dramatic problems that were solved last minute. These stories are fascinating and inspiring, but you don’t want to rely on this way of working.

Inspired by John Cutler’s post I wanted to write about boring teams. Or as Cutler calls them: boringly effective. In the same spirit, I recall a quote from a Swedish soldier deployed to Afghanistan a few years ago, when describing their mission, and the risks of it:

Becoming a manager

Thu, 17 Jun 2021 06:54:39 +0000

Putting on the high hat and stepping up on the stage

I have always visualized coaches with caps and managers with high hats

Transitioning from maker to multiplier is hard, especially if you are also taking on management responsibilities. About a year and a half ago I transitioned from agile coach to my first management position. My motivation at the time was to become a better coach by understanding the challenges of management. I wanted to learn new skills, and have an opportunity to lead, not just coach, a team. As I am now taking on the mentorship of a new manager, I am reflecting on some of the learnings I’ve had and how my work has changed.

Reteaming — often

Mon, 11 Jan 2021 08:15:12 +0000

or how to build a great product while on a boat

If something is hard — you should do it often

The challenge

When I started at Storytel our team consisted of six developers. My first task was to grow the team, and after an intense period of recruitment, we were 15. It was clear that we could not continue working as a single team. The normal symptoms were showing up: long standups, a lot of handovers, and lengthy meetings were necessary. The efforts of planning and continuously reporting status was becoming a big overhead.

Agile @ Storytel

Mon, 28 Sep 2020 11:37:02 +0000

Agile software development is by now a label getting pasted onto anything and everything. It is hard to know what it actually means and what practices and tools an organization calling themselves Agile actually apply. Still, I often get the question of whether we do Agile at Storytel.

While working as an agile coach I encountered many ways to organize and do software development. Some of them worked very well in a specific context, some were repetitions of things that have been tried for many years, but never really worked well. What they had in common was that they were all labeled Agile software development.

The art of possibility and self-leadership

Thu, 12 Dec 2019 08:05:11 +0000

One of the most powerful tools for leadership is self-leadership. Without it, leading a creative space is almost impossible. This post is a collection of valuable lessons on how to lead yourself.

I seldom reread books. One exception is the wonderful “The Art of Possibility” by Benjamin and Rosamund Zander. In the book, the authors present several lessons that are powerful tools for self-leadership. I periodically reread the book to remind myself, and I realize it is time to share these practices with you.

Øredev 2019 — sharing knowledge

Mon, 18 Nov 2019 13:34:13 +0000

This year’s sticker on my laptop

Before we dig into it — full disclaimer. I have been to every Øredev since 2007. That makes 2019 my 12th year. Considering that we celebrated 15 years, I have seen the conference grow, change and improve. I have also been on the program committee on and off for many years. For the last two, I have worked with the “People and teams” theme together with Martin Rosén-Lidholm.

Agile transformation happens in a team — not in a company

Mon, 14 Oct 2019 07:59:17 +0000

People don’t care which company they work for, they care which team they work in. Company visions, the acting of a CEO, company culture and brand are all important, but they are always trumped by the acting of your nearest manager and colleagues. Team culture trumps company culture. Team goals and visions trump company goals and visions. The trick is to align these.

While I worked with a department in a large financial organization to do an Agile transformation we saw teams ignoring change that happened on a department level. Or rather — they were not much affected. There was the launch of a new, glossy vision, a call to action of working differently and an ask to work with a different mindset. There were workshops, presentations, and more workshops. But at the end of the day, the team still worked with the same system, in the same way.

Addressing middle managers resistance to change

Tue, 24 Sep 2019 07:12:00 +0000

When working with a bigger organisational change — such as an Agile Transformation — I have observed that the biggest resistance comes from middle managers. In recent work I did with a department we spent a lot of efforts working with these managers, and learnt the hard way why many of our assumptions were wrong.

Talking change with upper management is easy. Most of them see the benefit of doing the change. It is cheap for them to support the change, because often they don’t have to do anything differently. They are attracted by the promises of greater speed of delivery, retention of people and the hero status of successfully moving the status quo. Sometimes they pay lip service to the change, supporting it in words, but not in actions. They point to the middle managers as the people that really have to change how they work.

Big and small bangs

Tue, 17 Sep 2019 06:22:07 +0000

Throughout my career I have always been a believer in making the shift to an agile mindset iteratively, in small batches. That means, start with a team, follow the pull and support the people that really want a change. The idea is to slowly reach a tipping point where the mindset shift starts spreading on its own. Whenever I have come across managers that want to do an “Agile Transformation” by forcing everyone to change overnight, I have strongly objected. Change takes time, and working in an agile way requires a shift in mindset, leadership and culture that takes even longer time to achieve. The whole notion of labelling a change project an Agile Transformation, and thinking you are done after a year, has gone against many of my beliefs (yes, even after I became part of one myself).

How to use me

Thu, 04 Jul 2019 06:10:24 +0000

A brief instruction of how to get the best of me. My motivation drops to the bottom of this picture.

I think it is important to take a moment checking up on yourself, figuring out how you are doing according to your own values. I recently spent some time introspecting to learn more about my own behaviours and how to be better at what I do. I want to share an insight I had about myself, and why I feel very uncomfortable in some situations. It is the insight of how to best use me.

The non secret formula

Fri, 28 Jun 2019 06:46:51 +0000

In a recent management meeting, we were planning future work. We were discussing where we should bet our efforts, and how we should prioritize the pieces of work that were on the table. The discussion quickly turned HIPPO. We have seen this happen before. These priorities are hard to explain and defend. Neither stakeholders nor people doing the actual work understand why. When pushed management risk slipping into explaining their priorities with because I say so. This creates disengagement and a continuum of the debate of opinions.

Value of a message

Thu, 20 Jun 2019 06:16:33 +0000

I was recently in a meeting with a management group listening to a presentation. The presenter, another manager, was telling a message that I had been trying to convey several times to the same group of managers. I was questioned at best, ignored at worst. But suddenly, the message came through loud and clear. People were nodding, asking to follow up questions and showing great interest.

Then I realized (or was rather reminded) that the value of the message received is relative (proportionate, or perhaps even exponential) to the trust and respect relationship between the messenger and the receiver. How this works very much depends on the culture of the organization.

The management vortex

Fri, 07 Jun 2019 05:01:52 +0000

While observing a group of managers working something dawned on me.

We all know that most managers create value indirectly. They don’t ship software, give service to customers or build anything of direct value to customers. Instead they deliver value indirectly by setting directions, creating environments, helping people grow and much more. The same is true for agile coaches and all other supporting jobs.

This means any work management does will eventually have an effect on those creating value. It could be new policies, meetings, alignments or other things. If this is done in support of what the value creators are doing (the team asked for help to remove an obstacle) the investment of changes in process or alignment meeting is worth it. However, if management is doing something to manage work or even worse manage the people, then the investment is only a burden.

Coaches coaching coaches

Thu, 23 May 2019 06:13:13 +0000

Inspired byYuri Malishenkoi created this visual story of my observation

I recently caught myself having a coaching stance when working with a group of coaches. And after realizing my own shortcoming I started being observant to how other people acted, and I realized many of us had the coaching stance. The consequence was we all spent time trying to observe and coach each other, and not much was being done in the meeting. Instead there was endless discussions, temperature readings and efforts to help each other.

Best practices are the worst

Fri, 15 Mar 2019 05:31:15 +0000

Working as an agile coach I am often asked to present best practices. What is the best way to run a standup? What is the best way to create a plan? What is the best way to run a retrospective? What is the best way to involve your stakeholders?

My usual answer is the classical it depends. This is where people give up on me and start asking what other companies of the same size and in the same line of business are doing.

Learn to rest

Fri, 21 Dec 2018 09:38:41 +0000

Learn to rest — not to quit.

This is a concept familiar to most people doing endurance sport. As a long distance runner I have a resting pace. If I feel the body is starting to wear, I can fall back to a pace that I can sustain for a long time. It is a pace where I can think clearly, examine my body and energy levels, and create a plan. This is an ability I had to learn. I experimented on long runs, and with the help of a pulse watch and listening to my body I found a resting pace that worked for me.

Takeaways from Øredev 2018

Wed, 12 Dec 2018 10:48:41 +0000

On November 19–21 I participated at Øredev, the prime dev conference held every year in Malmö, Sweden. Actually it was my 11th year at the conference, and I am not only participating, I am part of the program committee inviting speakers around the topics of people and teams, together with the ever so great Martin Rosén-Lidholm.

Many people ask me about my takeaways from the conference, so I thought I’d share them here. During the conference I tweeted my notes live from the sessions I attended, and you can still read them in my twitter feed.

New type of leadership

Thu, 04 Oct 2018 13:18:53 +0000

Over the years I have read plenty of books describing new ways of working. They are about a new, sometimes counter intuitive, paradigm. Some call it agile, some call it common sense (it seldom is) and some call it teal. There are many names, labels and methods but I have found one thing to be in common: working in this new way requires a new type of leadership. It requires managers to step out of their old paradigm of controlling and distributing work and start leading, growing and empowering people. It requires new ways of thinking and new tools.

Delivering value my first week

Fri, 17 Aug 2018 12:59:37 +0000

Great teams will focus on delivering value — fast. They deliver small chunks of value, often and with little overhead. I have seen software dev teams practice this, and it delighted both team members and customers receiving the value. Really great teams will introduce team members to this way of working by having them deliver something into production during their first week.

Starting a new job as an agile coach I decided to try this method. I set out to deliver value as quickly as possible, at least within my first week. This forced me to go looking for opportunities to help out. Value goggles on!

Research is an iterative process

Fri, 15 Jun 2018 08:37:51 +0000

Researchers have found that software developers become more productive when listening to banjo music.

You read the title of an article that promises a new truth. Exciting. The article describes how researchers have conducted experiments and confirmed that they can see an increase in productivity when exposing poor software developers to banjo music. The newspaper states this as an absolute truth. What they are forgetting is that research is an iterative process and absolute truths do not exist (neither do silver bullets).

Tools for distributed teams

Fri, 04 May 2018 14:50:17 +0000

As with any craft, you will do better with the right tools, while bad tools will slow you down and create frustration.

Before digging into my toolbelt I want to point out that any tool is pointless without discipline. Working agile, and working distributed, requires a large portion of discipline. The threshold for communication can be much larger than just shouting across the desk. It takes some getting used to your team members being available online instead of present in the same room. It requires discipline to stay transparent and open when sharing becomes unnatural.

The myth of the everlasting team

Fri, 23 Mar 2018 14:17:28 +0000

Prescriptive agile models, such as Scrum, preach that a co-located, strong team will bring success. I believe this is an old paradigm. In a recent post I explored what it means to have a distributed team.

In this post I want to kill the myth of the everlasting team.

Everlasting teams

Agile usually comes with the myth of the everlasting team. A strong, stable team that continuously improve with every iteration. The team is so stable they can estimate their work, create burndown charts, predict when they will be done and plan several iterations ahead. If the world around them changes, it is preferred to keep this strong team intact and give them another backlog to burn. In this mythical team, everyone is completely focused on the task they are doing and always working at their maximum capacity.

Working from elsewhere

Fri, 23 Feb 2018 15:07:06 +0000

Agile prescriptions, such as Scrum, keep preaching for co-located, strong teams that share a room and take on new work as the world around them changes.

I have stopped believing in this. As the world around us changes, we need to adapt. Strong co-located teams are part of an old paradigm that no longer is true. The reality has changed, and it is time we face it and adapt.

Innovation — but why, and how

Mon, 29 Jan 2018 13:55:12 +0000

Innovation is such a positive word. We can slap it onto almost anything, and make it look good. There is a magical mist around innovation and how it comes into being. We observe bright minds churning out good ideas that become disruptions in the market. We try to be as cool coming up with crazy ideas that we cram into our products. Very few of these become disruptions, if they solve any real world problems at all.

Software is made by people, for people

Fri, 08 Dec 2017 18:59:14 +0000

Many years ago, when working as a consultant, wringing out lines of code, I came to this simple, but powerful realization. It changed the way I look at software and my whole career path.

I was on an assignment at The Big Company, working on their Big Enterprise Backend. We were dealing with multiple maintenance issues, handovers in the project and integration with other Big Systems. Most of the maintenance was done by consultants from, and sometimes located in, India. They were detached from what we were trying to create and had little understanding for the problems we were trying to solve. Even though we used state of the art technology, worked hard with TDD to ensure quality and worked according to agile principles, the problems persisted. Users were complaining about missing features or simple tasks being too complicated to perform in the system. Then it hit me: our software is made by people and is to be used by people.

Building skills — on parental leave

Mon, 04 Sep 2017 10:01:42 +0000

When telling people that I will spend six to eight months away from work and become a stay-at-home-dad reactions were mixed. Many expressed concern for my career and skills as a coach. My approach is the opposite. I am learning and sharpening many skills that I use as an agile coach. By sharing some of these I want to promote parental leave as a skill builder rather than the career killer many believe it to be. I believe spending time away from work, with my kids, contributes to the wholeness (as defined in Reinventing Organizations by Frederic Laloux) I bring to work.

Eyes on the prize — outcome over output

Thu, 13 Apr 2017 11:43:37 +0000

Lately I have been thinking about why so many software development teams are focused on creating new functionality in a product, but know very little about how the product is actually used or what problems they are solving.

Inspired by Jeff Gothelf’s article on managing projects for outcomes over outputs I would like to share some of my thoughts on the topic.

Outcome vs output

First, let us define what the difference is. Outcome is what customers are after (sometimes without knowing it). Most people do not want to buy a drill, they want holes. Most people do not want to buy a camera, they want photos taken. Applied to software there is (should be) a purpose with the software. “We want to use this website to sell more of our products”, “We want to use this software to run our business more effectively (by making data driven decisions)”, “I want to keep up to date with what is happening in my community (by accessing social media on my phone)”. These are outcomes the customer is looking for. But we often focus on the output: the website, the app, the software. Even if we create a beautiful website, deliver it on time with state of the art technology — but it does not help the customer sell more of their products — we have failed to deliver value. Therefore, we need to focus on the outcome.

Takeaways from my first design sprint

Fri, 23 Dec 2016 11:59:14 +0000

Last week I facilitated my first design sprint, with Tom Kealey as a sidekick. It was a textbook example of a sprint as described in The Sprint Book.

In this post I will share what I learnt from facilitating this event.

Summary

I learnt tons from this sprint. Not only about the topic we explored, but also about the process and about our own organisation. I love this way of working, and it is perfect when exploring the great unknown. It is a great way to perform research in new areas, or revisit unsolved problems. There is focus on the problem at hand, alignment around the solution and validated learning. One of my biggest takeaway is that a design sprint is optimized for learning. You will learn a lot. The output and the solution will not solve any world problems, but suddenly you have a map of that great unknown. There will still be a lot of unanswered questions and new peaks to climb, but you will know where those peaks are and what part of that map you want to explore further.

Innovation — create a space

Thu, 08 Dec 2016 13:39:56 +0000

What is the first thing that comes to mind when you think about innovation? Is it space travel, medicine and the Nobel prize? Is it new business models, computer chips and programming languages? You can probably name several disruptive innovations connected to these areas. But do you ever think of a cross functional team delivering software as innovative? Do you call their work innovations? What would change if you did?

Hierarchies and networks in organizations

Tue, 11 Oct 2016 13:54:05 +0000

Inspired by John Kotter’s article Accelerate I am starting to realize that hierarchies and networks need to coexist in a large organization. Organizations that solely run on hierarchies operate from a machine paradigm. They are great at effectively producing copies of the same thing. Everyone knows what to do. Decisions are taken at the top of the hierarchy. Progress and speed is measurable and efforts are spent making this environment more predictable. There are many examples of companies that successfully operate from this paradigm and are doing well. Until the market suddenly shifts, new technology challenges the whole being of that company or new opportunities emerge. Hierarchies cannot handle change and quick changes of direction. Turning this big ship around takes a lot of time and effort, if at all possible.

Why I share — tacit vs explicit knowledge

Wed, 07 Sep 2016 12:58:36 +0000

While reading The Connected Company by Dave Gray I came across Nonaka’s spiral of knowledge as presented in his book The Knowledge Creating Company and more easily accessible in an article on HBR.

Spiral of knowledge

The books and this model describes the difference between tacit and explicit knowledge. Explicit knowledge is things that are easy to see and measure. It consists of documentation, software, instructions, models, processes and ways of working. Hierarchical organizations love this kind of knowledge because it is easy to measure and compare. Tacit knowledge on the other hand is in the minds of people working. It is the mastery, skills and unconscious knowledge of someone who knows how to do the work in a great way. This type of knowledge is almost impossible to measure, but without it the company will fail. In a knowledge creating company these two types of knowledge interact, creating new knowledge. Magic happens in the transitions between tacit and explicit knowledge. The only way to pick up tacit knowledge is to spend time with a master and learn from the way they do work. Copy them and understand how they are doing things, and why. By putting this into writing and sharing this information we make the knowledge explicit. By giving this to others, they can train on this explicit knowledge and build new tacit knowledge. When reading this I realized — this is exactly why I share.

Reinventing organizations

Thu, 18 Aug 2016 07:59:20 +0000

I recently read Reinventing organizations and was inspired. The book provides proof that self managing organizations exist and can be successful. There are many good takeaways from this book, everything from inspiration to practical tips of how to handle conflicts, make decisions and engage people. In this post I will sum up my biggest takeaways and what inspired me.

The model

Laloux describes paradigms that organization operate out of as different colors. Here’s an overview of the model:

Gamifying knowledge sharing

Thu, 16 Jun 2016 10:24:43 +0000

Sharing knowledge is essential for an learning organization. We want to create an environment where knowledge and ideas are shared between team members, across teams, between managers, across departments and across organizations. In a learning organization people are continuously learning new things. Sharing what you learnt or discovered becomes a reflex and people get inte the habit of building on each other’s ideas.

Have you ever been to a conference where the atmosphere is sharing and caring? And then being met with indifference when trying to share your experiences and new found knowledge in the organisation? Or have you realized that teams work in isolation, reinventing the wheel without sharing their discoveries with the rest of the organisation? I have seen this happen in many teams and companies, and have wondered how to change the attitude towards knowledge sharing.

Creative Leadership — a course at Kaospilot

Mon, 02 May 2016 08:18:17 +0000

After attending all three modules of the fantastic Creative Leadership course at Kaospilot I want to share what I learnt. An insight I have about myself is that I learn by sharing, and to make what I learnt stick, I will share and discuss with you.

It starts with you

As with any type of leadership or coaching the leader has to be rooted. You have to know yourself and be able to lead yourself to be able to lead others. The intention of this module was to Explore how to lead myself and others in creative collaboration.