Jump to content

My Personal Blog


“Our deepest fear is not that we are inadequate. Our deepest fear is that we are powerful beyond measure. It is our light, not our darkness that most frightens us. We ask ourselves, 'Who am I to be brilliant, gorgeous, talented, fabulous?' Actually, who are you not to be? You are a child of God. Your playing small does not serve the world. There is nothing enlightened about shrinking so that other people won't feel insecure around you. We are all meant to shine, as children do. We were born to make manifest the glory of God that is within us. It's not just in some of us; it's in everyone. And as we let our own light shine, we unconsciously give other people permission to do the same. As we are liberated from our own fear, our presence automatically liberates others.”

― Marianne Williamson, A Return to Love: Reflections on the Principles of "A Course in Miracles"
Show all categories

Titles that don't mean what they say and words that make no sense - is this how we wnat the future to be?

Product Manager own the product while the product owner manage it. Scrum Manager work both towards management and the team and everyone is an engineer, but have no scientific approach to anything they do.

Sometimes I feel that the world has gone mad and that titles as well as words are used without logic or even thought sometimes.

A Product Owner, owns the product.
A Product Manager, manages the product.

It is defined in the titles themselves...

A Scrum Manager is just a manager in a fake Scrum setting, or you would not need a manager to begin with. Just throw out Scrum and start working properly instead and call the position a team leader or team manager that fit the work that is being done. Or just use Scrum if you prefer that and have a Scrum Master.

A Business Analyst work on the business side to help sort out business needs. A Requirement Analyst help to break down business needs to requirements.
Both roles are facilitating to act as translators and guides. They have no deciding authority, but work as the bridge between the business side and the implementation side.

Requirements are legally binding contracts of work the defines what should be done and how to verify that the work is done according to what is being needed. Requirements should be defined based on the level of trust between the business side and the implementation side.

A Full Stack anything is just a junior pretending to know more than they do. Unless you define the stack and what full means, you are just...well full of it.

Engineers work with a scientific approach and unless you actually can explain how you conduct our work with a scientific approach, then you are not an engineer. And no, Agile is not a scientific approach.

Projects are fixed in time, cost and scope, and they are funded as investments, not operational work. If whatever work you are doing is not fixed, and it is not funded through an investment budget, then you are not working in a project.

I know making things up to make you feel important and using words that are wrong because that is "how it has always been", but we are just spiraling towards understanding what we do and what we mean less and less.

How about we stop using what has always been and start applying logic to our workplaces?

Or has that ship already sailed, and we are doomed to a future when words no longer have meaning or logic to them? Will we just talk gibberish like management consultants and c-level management spewing buzzwords to sound important?

What do you think?

Jimi Wikman
By 💫 Jimi Wikman in Thoughts ·

First week at Sii Sweden

This week I started my new position as Atlassian Architect for Sii Sweden, an Atlassian Platinum partner, after a lightning fast interview phase. It has been quite the interesting week with onboarding and getting to know the massive organization that Sii International is. I am now working from a new location in Stockholm that I do not have been to very much, so it is interesting to explore the area as well.
Some of you might know that I have been looking for a new employer after QRIOS decided to close down the part of the organization I was supposed to work at after I left Sinch. I had the luxury of having three amazing companies offering me different positions. Sii Sweden cane in last minute and I had 3 interviews in just a few days, and then they gave me an offer. After weighing my options, which was not easy with three amazing offers, I picked Sii Sweden.
I started working on Monday this week and so far the journey has been great. The Swedish CEO Miguel Vergara is great, and he has done everything he can to make me feel welcome. The Sii head of Atlassian Maciej Szostek have provided a ton of information on what his vision and plans are for the Atlassian part of Sii and I have to say, he has me sold on those plans! I am really looking forward to work with Maciej and the rest of the Sii Atlassian team towards that vision.
Speaking of the Sii Atlassian team I have only met a few so far, and they are amazing. I am not easily impressed when it comes to Atlassian competence, but working with my fellow Atlassian architect Wojciech Miecznikowski and one of our amazing Atlassian consultants Piotr Mazij, I am impressed. They clearly know what they are doing and with experts like that on my side... well, let us just say I feel good about the future :)
As you might notice my Atlassian colleagues names are not Swedish and that is because Sii Sweden is a part of Sii Poland. Sii Poland is a massive organization with 7500+ employees and Sii Sweden is a small, but growing, extension of that organization. I was very impressed about the origin story of Sii Poland that was built from one man to the impressive organization we have today. You can watch the impressive story that our CEO Gregoire Nitot undertook to build the Polish branch of Sii in this video.
Globally Sii have 16,000 employees in pretty much all areas you can think of, and it all started with a French company called Groupe SII back in 1979. For me this is an interesting situation because in Sweden we are still small in terms of organization, but in Poland we are quite big and globally we are massive. It provides an exciting opportunity to help our Swedish organization grow, and I especially look forward to growing the Atlassian side of Sii in Sweden.
Although I have only been with Sii one week now, I feel very good about the work that has been done so far and the vision for the future for both the Swedish branch and the Atlassian business area. There are many exciting opportunities to explore and with the support of a massive organization with high competence in almost all fields you can think of and coworkers that are amazing...
The future is so bright I have to wear shades (Timbuk 3 - 1986).
Jimi Wikman
By 💫 Jimi Wikman in Thoughts ·

Why is it that we dislike learning from experience when it comes to how we measure our work?

You would think that becoming exponentially better at measuring and anticipating risks is something most organizations would spend time and money on. Especially since it is the core of making sure we create value from our work and to manage our financials as an organization.

Just as we as a society benefit from learning from history so we can avoid wars and cultural destruction as well as genocide, surely we as organizations would emphasize on preventing disasters, both long term and short term?

Yet, many organizations put zero effort into long time learnings or even document neither triumphs nor disasters. Instead, we run as fast as we can and any learnings we make along the way have the stickiness of Teflon.

While the definition of insanity really has nothing to do with repeating the same bad thing over and over as the term is a legal one and not a medical one, I would argue that constantly ignoring lessons from your failures or successes is stupid to the point of negligent.

If you don't make estimates in measurements that can actually be evaluated and learned from, then you are robbing yourself and your organization of that learning experience. You are hindering your own growth as a professional, and you are most likely hurting your organization by repeatedly failing to produce the right value at the right time.

It is not enough to produce value after all. You have to create the right value at the right time, and you need to continuously improve your competence in making those estimations.

You either learn from your experiences, or you are doomed to repeat them.
Jimi Wikman
By 💫 Jimi Wikman in Thoughts ·

Have we forgotten to think INSIDE the box?

We have been told to think outside the box for so long, so maybe we are forgetting how to think INSIDE the box?

We placed things in the box for a reason, but maybe we have forgotten why we did it in the first place?

If we always think outside the box, why do we have the box at all and does that strange box we are supposed to think outside actually exist anymore?

Personally I think the only thing that matters is that we THINK, regardless if it is inside or outside the box.

Don't just do without thinking...
Jimi Wikman
By 💫 Jimi Wikman in Thoughts ·

Why do you insist on keep digging holes where you stand?

If your goal is to build a road to the future where your vision is aimed, why do you insist on keep digging holes where you stand?

What makes less sense is why you compare the speed with which you are digging those holes instead of measuring how far the road towards your vision you are getting?

Unless your road to success is a hole straight to hell, perhaps it would make sense to lift your gaze towards the horizon instead of staring down at your feel at the bottom of the hole you are so frantically digging?

Vision requires goals. Goals require planning and planning require focused execution. Ad-hoc ways of working where you make things up as you go along without focus, goals or vision is just you digging a hole where you stand.

Measuring the speed of which you dig your hole or patting yourself on the back for thinking less and doing more is a rather interesting choice if the goal is to move forward...
Jimi Wikman
By 💫 Jimi Wikman in Thoughts ·

Is your team an engineering team, or a mining team?

Your team is either an Engineering team building towards a vision, or a mining team digging up value as they find it. You can't do both.

Many teams are confused about of these two and as a result they get the wrong result.

If you are working with continuous deliveries then your goal is to always move towards your visions and goals.

If you are working in a project, or in a R&D setting with ideation and exploration, then you are working towards finding as much value as you can in a set amount of time.

If you are working in a continuous delivery, and you are just digging where you stand, then you are not working towards your goals and visions, but you are trying to dig up as much value as you can in the time available.

This is frustrating because instead of moving forward, you are going downward. So make sure you know if your aim is forward or downward and act accordingly.


What direction is your team working towards?

If you are struggling to deliver today, then this could be why.
Jimi Wikman
By 💫 Jimi Wikman in Thoughts ·

When people talk about technical debt I always wonder if the debt is intentional

When people talk about technical debt I always wonder if the debt is intentional or just the result of not thinking things through properly.

In my experience systems that are in bad shape tend to be so for a handful of reasons.

- Little to no structure - Instead of having a strategy on how to build systems, people make things up as they go. With many people doing this, the end result is never good.

- Little to no deep thinking - Instead of thinking things through properly people do a quick brainstorming on a whiteboard and then implement. Missing important aspects of the implementation due to not doing any deep thinking. IN this case speed kills.

- Unclear or obfuscated requirements - When the need is never really defined and/or constantly shift then you can only do so much thinking before everything becomes reactive and quality drops like a stone.

- No time to do things right - Stressful time limits, usually from bad requirements or lack of good estimations, reduce the time available to actually think things through. This can also be an organization issue if the culture is to just run and fix whatever you can here and now to make things look good instead of actually doing good.

- Lack of care - People that are treated poorly stop caring. It is as easy as that. When people stop caring, which usually comes from disrespect or abuse in the workplace, then there is little you can do to prevent damage from happening to the service or product.

The fix is easy: Treat people with respect and make sure there is time and expectations to think things through before you build things.

Ad-hoc running is madness, and it does nothing to help making the organization successful.
Jimi Wikman
By 💫 Jimi Wikman in Thoughts ·

Is it fair to blame Agile for the stress related health issues affecting management?

Is it fair to blame Agile for the stress related health issues affecting management? Are we sacrificing management for development teams to self-manage and if so is that a good thing or a bad thing?

It is no secret that management has become increasingly more difficult in the wake of the Agile movement. At least in the part of the Agile movement where teams are self-isolating and making up their own way of working with no alignment with the rest of the organization.

I have seen managers pass out in meetings and several have broken down to the point where they needed medical assistance. This is not uncommon and of all positions in a company I feel that middle management is by far the most stressful at the moment.

I believe this is due to a bad culture of always trying to be as fast as possible, poor communication between management and the teams and of course misaligned work processes that forces management to do far more work than they should have to.

While it is easy to blame Agile frameworks like Scrum for this, but is that really fair? It is not in Scrum that the teams should isolate themselves from management, at least not directly, but it seems that this is something that teams do on their own.

The gap between teams and management is growing and the question is if it is now worse than during the days of silo work in what we refer to as Waterfall, or when we will pass that point.

Manager across the globe are suffering, and I don't see anyone talking about this, or the cause of why they do. I think we should talk about it and the increasingly selfish behavior that is on the raise with internal tribalism feeding conflict between groups in the organizations instead of collaboration...
Jimi Wikman
By 💫 Jimi Wikman in Thoughts ·

Your internal production systems are not toys.

Your internal production systems are not toys. Using them as such and claiming it is so you can be "creative" is a clear indicator you and your organization are immature as an IT organization.

Internal production systems are critical for your daily operation, otherwise you would not use them. Treating those systems as toys by not having proper governance for access, having little to no governance over integrations and allowing configurations without any strategy or governance is a disaster waiting to happen.

While innovation is important, it should not come at the expense of security and legal compliance. With regulations like GDPR you must have full control over your data and if you want any form of security you must control access and integrations.

In mature organizations you solve this by having separate systems where people can play around and be creative, and then they control the change process before any value found during these play sessions are implemented in production systems.

Immature organizations not only have a problem with security and legal compliance, the people that use these tools as toys also tend to behave like children when their toys are taken away from them.

This makes transitioning from an immature organization to a mature one an unpleasant event, and you need to pick your "parenting" style when doing it depending on how much conflict your organization can manage...

Jimi Wikman
By 💫 Jimi Wikman in Thoughts ·

Take back control of common sense

DevOps should not need to be implemented, it should be the norm. An agile mindset should just be common sense. What you need to focus on is understanding and respect in 2025 so you can build a holistic governance organization that can capture all the amazing ideas on how to work better holistically together.

Put the ready-made frameworks and methodologies you have floating around in all their bastardized forms aside and start building your own methodologies today.

No buzzwords.

No Made up roles or rituals.

Just take what works, name it after what it does and learn more about your co-workers need across your organization.

Ge those egos in check and start looking out for everyone and not just yourselves. Build that trust that you can spend time and energy looking out for others because you know they will do the same for you.

Take back control of common sense and apply it to your ways of working and start looking at your problems and opportunities from a holistic perspective!
Jimi Wikman
By 💫 Jimi Wikman in Thoughts ·

Projects are not that difficult

If you are running a project, then you use Project Management as the method. If you run multiple projects, then you run Program Management as a method. If you run continuous deliveries for a product or service, then you use product/service management as a methodology.

If you write code in either of those, then you use whatever method you want that fit whatever framework you have selected. Your work is the same, and it is only the level of detailed requirement and time restrictions that are different.

If you estimate correctly, then the management format should be irrelevant for you. If you can't estimate or work with requirements, then projects will feel like hell on earth and most likely fail.

This is not rocket science and if you want to be really good at your work, make sure you become an expert in working in project format because continuous deliveries will automatically be easy at the same time.

Don't blame projects for your lack of competence in estimation and working with requirement in a fixed delivery setting. Learn it, or continue to let everyone involved to suffer.

It really is that easy.
Jimi Wikman
By 💫 Jimi Wikman in Thoughts ·

If you are focusing on Customer First, then you are focusing on the wrong thing

If you are running a project, then you use Project Management as the method. If you run multiple projects, then you run Program Management as a method. If you run continuous deliveries for a product or service, then you use product/service management as a methodology.

If you write code in either of those, then you use whatever method you want that fit whatever framework you have selected. Your work is the same, and it is only the level of detailed requirement and time restrictions that are different.

If you estimate correctly, then the management format should be irrelevant for you. If you can't estimate or work with requirements, then projects will feel like hell on earth and most likely fail.

This is not rocket science and if you want to be really good at your work, make sure you become an expert in working in project format because continuous deliveries will automatically be easy at the same time.

Don't blame projects for your lack of competence in estimation and working with requirement in a fixed delivery setting. Learn it, or continue to let everyone involved to suffer.

It really is that easy.
Jimi Wikman
By 💫 Jimi Wikman in Thoughts ·

In a toxic workplace honesty is punished and silence is rewarded

In a toxic workplace honesty is punished and silence is rewarded. In a toxic workplace your reaction to other's disrespect makes you the problem. If you speak up, then you are considered problematic, and you are branded as disloyal.

If you are feeling that you must stay silent to avoid being branded as problematic or disloyal, that is a toxic workplace. If you feel that you must reduce yourself so you do not threaten others ego under the guise of the company mantra that you should be "easy to work with", then you are in a toxic workplace.

If you are bullied to change your language to avoid hurting someone's feelings, even when the words you use are not intended to hurt, then you are being censored and disrespected, and you are in a toxic workplace.

If other people are valued more than you based on their gender, color of their skin, culture or any other generic trait, then you are in a toxic workplace. Your value comes from within and if that is not the fact in your workplace, then it is a toxic workplace.

Bad leadership fear honesty and toxic workplaces thrive in silence. Fear is not commitment or loyalty and disrespect disguised as kindness is not company culture.

It is abuse.

If you have the option to find another workplace, do it as quickly as you can. If leaving is not an option, then find help outside the organization and do whatever you need to survive during working hours.

Be safe and never accept that the price for loyalty, or respect, is the loss of your voice.

You deserve better than that.

Jimi Wikman
By 💫 Jimi Wikman in Thoughts ·