My Blog (154) My Swedish Blog (1313) Community Blogs

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"

By 💫 Jimi Wikman · March 23, 20251 yr

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?

By 💫 Jimi Wikman · February 22, 20251 yr

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).

By 💫 Jimi Wikman · January 30, 20251 yr

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.