Author: Ola Sundvall

It’s inevitable – I need to write about AI

And true to my habits, it’s going to be from a “is it just me” perspective.

I recently decided to make use of Claude (on a free plan so far) to act as my business advisor, since my so-called transition from my former (still being?) consultant approach to more of a peer is stalling. Inspired by the explosion of AI agent postings in all feeds everywhere, I thought I should start to build my own team in order to start a marketing campaign or something similar, maybe at least get some momentum in daily marketing work.

I got some advice that I didn’t like so much from the bot, since it required me structuring my archives in order to feed the agent with information about me so that we should be somewhat qualitative. I then turned my question over to more of what I am (or should be) and how to act. The prompt looks like this:

“With the background I presented initially and the file I just uploaded, I need some help with ideation. I’m struggling with two huge questions: What do I want to do? What could be a market where my experiences are valuable and I would have a good chance to really stick out and “stick” with prospective customers and what value should I bring to them? I have so hard to change route from the old-school consultant that I have been and maybe not been good enough as. I also have an idea about putting together a team of diversely skilled AI agents in order to get some momentum in an ideation process, but I don’t know if it’s worth the costs and effort.”

Now things started to turn in more interesting directions. To this text, I had attached my profile or CV in English, and Claude told me that I possibly undersold myself and we started to elaborate on this, putting the whole agent project aside for a while, since this wasn’t of importance right now.

I got a couple of alternatives of how to present myself and I picked one with, stated by Claude, more niche and possible higher risk, but speaking to the “curious and analytically minded” (that understand what I actually offer?).

I reasoned that it’s worth taking the risk of not being understood by all. The ones who do are probably more worthy to approach anyway. And since I gave Claude the link to my website, it was hard to avoid a rebuild in the direction we had been taken on this.

So, the web page was radically rebuilt from my earlier radical rebuild, and it felt okay.

The next step was to dig into my LinkedIn profile, where I recently made a shift towards being a facilitator. The business for facilitators has recently started to erode, since AI tools can do a good portion of the work facilitators have done until now (this can be a bit exaggerated since very many organizations are far behind the ones that strive for real digitalization, but one cannot shy away from it entirely).

This is where I was forced to halt and think things over. I was in an earlier stage given a tagline and a text for the “about” section on LI, and I took the tagline and pasted it as it was, looked okay. Then I asked Claude to give me a new draft for the about section, looked okay and I pasted it. Those two elements are the ones that are there now at the time for writing this, but what came next?

I got a recommendation to write a post about me describing my skills and add this to the “Featured section on my LI page”, and so I asked Claude to give me a draft (at this point I was so accustomed to Claude doing stuff for me so it felt just natural). But – it didn’t feel good. The post is here, as-is:

“Most organizational problems aren’t people problems

When a team underperforms, the diagnosis is almost always the same: wrong people, bad attitude, poor leadership.

It’s usually wrong.

In 25 years of working inside organizations — defense, healthcare, manufacturing, retail tech — I’ve seen the same pattern repeat across sectors, sizes, and cultures. The people are capable. Often experienced. Frequently aware that something isn’t working.

What’s broken is the design around them.

Three structural flaws show up more than any others:

Unclear mandate. The team doesn’t have a shared, explicit understanding of what they’re actually responsible for — and what they’re not. So they absorb work that isn’t theirs, fail to deliver what is, and gradually lose confidence in their own judgment.

Uncontrolled intake. Work arrives from everywhere, in every form, with no triage. The team is perpetually reactive. Nothing gets finished properly because something more urgent always appears. The list grows. Meetings multiply.

Invisible technical debt. Infrastructure, tools, and processes that nobody owns and nobody has a plan to maintain. Everyone knows it’s a problem. Nobody has the mandate — or the budget line — to fix it.

None of these are HR problems. They’re design problems. And they won’t be solved by a team-building day, a new manager, or a strategy offsite.

They’re solved by looking at the structure honestly, naming what’s broken, and building interventions that hold.

That’s what a business architect does.

If you recognize this situation — in your team, your organization, or somewhere you’ve been — I’d be interested to hear which of the three it was.

I just felt that this is maybe not me anyway – this is an opinion coming from an engine that I have fed with possible exaggerations and descriptions of who I have wanted to be somewhere in time, but does it align with what I want to be nowadays? I honestly can’t tell and I haven’t been able to tell for the last three or so decades, so how could an AI that I have known for just a couple of days and given a thin slice of myself know? The text is valid for sure, but this is more of an alias I have strived for in a period of my life. I have also noticed the many solopreneurs out here present an identity they want to be while actually working lower in the value chains, and it’s kind of sad.

This made me realize that building myself is a job I must do myself and I need to carve out the real me, what I want to do, and why. This is in a time when delivering advice as a service is so (possibly temporarily) disrupted and so many are both searching for solutions and so many searching for the next gig. Being authentic is the most important thing, but which authenticity should I choose? And in what way does this make me stand out from the crowd? There are a dime a dozen like me fighting for being seen, is it really meaningful, or should I continue experimenting with Claude and see how far it can go?

2026-04-01
Me, an AI native business owner? Sure, why not

Or do I have any other options?

My feeds suddenly started flooding with content about AI use recently — but all of a sudden on another, deeper level. Not sure what triggered it, but I think it was my interest in OpenClaw and the explosion of digital (AI) creativity that followed. After all, your feeds are always a result of your own earlier actions in them. Never forget that.

My interest in AI development (or application) has been lukewarm, because I’ve had a hard time seeing the real game-changing benefits from my perspective. I’ve mostly been working with more or less sensitive information, in more or less regulated businesses, where public AI services simply aren’t viable options. I’ve also been a bit ambivalent because of the very polarized debate I continuously follow, mostly on LinkedIn. Should you join the enthusiasts or should you join the big tech critics? Both sides make more or less valid points, and it’s easy to just stay silent and watch.

I’ve also been trying to understand the concept of AI agents and what they can actually do, but it never felt tangible in my professional context.

A couple of months ago I attended a webinar where the theme was the importance of really going deeper into AI knowledge, demonstrated with practical examples. And once more I found myself thinking: “How can this be applied to my business? Not everyone can suddenly become a coder — nor should they, because there’s so much in the world that needs to be done or delivered that has nothing to do with coding. I’d better stay with my thing and try to do my very best in what I already do.”

And then it clicked. Not from a webinar this time, but from stumbling over some presentation covering the idea of building business teams based on AI agents.
This turned everything upside down. The moment I understood that you could actually assemble resources — profiled and directed exactly the way you want — it opened the floodgates. I started generating ideas so fast my brain went into three-shift mode. Part of that is just who I am: unable to leave technically things alone, low fear of tinkering with IT, but also with enough of a grasp of technical design and security to know when something is actually solid versus just exciting. But even accounting for that — this felt different.

Still, I can’t stop pondering what this means for the bigger picture. If a huge and fairly diverse part of the population suddenly starts building small, hyper-effective sales and service machines — what do markets actually look like then? To whom are we all going to sell? Will we flood all “human prospects” inboxes with cold emails in way that makes traditional marketing wreak havoc? And what really creates value in the future if everyone can spin up their own value creation, creating value for their own needs almost overnight?

This applies mainly to service markets, of course. Houses still need to be built. People still need healthcare. Food still needs to be produced. But market mechanisms in the service space could, in a not-so-distant future, become subject to a pretty brutal overhaul (partly already ongoing, also known as “social media marketing”, er).

And the direction of that overhaul? I genuinely don’t know. But I’m thinking about it a lot. Meanwhile I will start building my team, or maybe multiple teams…

2026-03-19
Agentic AI and fear of the MS SharePoint phenomenon

I attended a webinar the other week where the topic was discussing the promise of using AI agents that you can use to ten-fold your capacity. This webinar was arranged by a host who always follows the same pattern in their webinars. They talk about a subject with a fairly high FOMO factor, or presented as “this is HUGE” — you are scared of missing out on something — and yes, at a given point in the seminar, you receive a heavily discounted offer to take a course on the subject being discussed. And by then, they have created so much FOMO that people are very inclined to sign up for a course like this where you get a certificate, and everyone is then happy and has suddenly got a feeling of having an expanded capability. That’s always all well and good, right?

This forced me into deeper thinking about this concept of “Agentic AI.” And yes, it is fantastic for being able to automate things you do. Like, for example, what I am doing right now; recording a voice memo as a draft for a blog post in Swedish, letting an AI transcribe it to text and translate it to English. Then I can publish it, and in that way, I save a fair amount of writing time—which, strictly speaking, I shouldn’t stop doing completely, because then I might lose the ability to actually express myself in writing, even if I don’t believe that [will happen] in the short term.

In the webinar as well as in public spaces, there is and has been for quite a while, a lot of talk about how, in these contexts, with the help of AI agents, one should be able to do programming. So, you are essentially replacing the developer with an AI agent and the ability to write code automatically, where they say that English is the new programming language. This is incredibly alluring, and it lowers the barriers for an incredible amount of people who then — given that you pay either, well, 20 or 100 USD a month, depending on which plan you choose to go with on this kind of AI service. In this case, it was about Claude, which is probably, right now at least, the service that perhaps has the best capability when it comes to Agentic AI-supported programming, or vibe coding or what you might call it.

Where they also talk about building apps, they talk about updating web pages, perhaps even creating a web page very quickly and easily, which you even can let the AI agent publish on the web, and then everything is done. The webinar in question was not focused on security; they made that clear right from the start that “we are not talking about security here, we are talking about possibilities.” And sure, you can do that, but it is still the case that in practical application in everyday life, it is inevitably so that you must address the security question as one of the first things you do. Because you can’t just drop a webpage, for example, on the internet and let it be so full of holes and security gaps that it basically becomes unusable.

The entire web is boiling with sniffing and searching for security leaks and holes and it is ongoing today with such speed and intensity that one might almost not understand it. So, you simply have to bring security along with you, all from the start.

Another thing I have thought about is that if everyone starts writing code by speaking English with a prompt, then it will be the case that this will become code that — wherever it is implemented — no one reviews. Then the quality might end up being “so-so.” What is worse is that if you do this in an organisational context, then we will also have a future problem that has an analogy in a story from my own experience that I thought I should recount here:

This was somewhere between, well, 2010 and 2015, when I was assigned as delivery manager for a SharePoint platform (among a slew of other (huge) platforms and systems) at one of Sweden’s largest government agencies. MS SharePoint was implemented as a global intranet solution for the entire organisation and everything was okay with delivery and, of course, too slow progress in development and maintenance.

Note that this was before MS 365 and the cloud paradigm hit the world, so we lived in an on-premise universe.

The phenomenon that started to emerge was that creative employees who ‘cracked the code’ of configuring SharePoint started building such clever pages for their sub-organisations, teams, or departments/units that they created fantastic tools for the business to use. In some cases, these became more or less critical as tools for the local entity to rely on.

This was great, initially; everybody was enthusiastic and development was well anchored in the business. A problem arose though, when these code-cracking individuals suddenly left for another job or a new position, because then there was no one left who knew what they had done to create the tool. When someone later wanted to improve, change, or perhaps repair something that wasn’t quite right, there was no one to take over and solve the problems that arose for the organisation, or for the local department using the sometimes heavily configured SharePoint space.

I had several quite tough conversations and discussions with our internal client, who felt that this was something we, as maintainers of the SharePoint platform, had to solve — that it was our responsibility to take care of business-caused ruptures due to natural changes in the organisation. I replied to the client that we have no idea what the business units are building and what needs it’s based upon. It’s simply not possible for us (as we are organised, based upon our agreed mission) to manage unknown code or unknown configurations that we don’t understand, especially since there is no documentation anywhere. There’s no foundation for these solutions within the application management team at all. We manage the standard platform in an agreed configuration exactly as it is when deployed. We find it very difficult to take responsibility for what users create in terms of user-centric configuration and content. We simply don’t know what the users are doing.

It was considered upsetting that we had such a ‘nonchalant’ attitude towards our ”mission” (obviously a mission with a sliding definition based on mood-at-the-time). But it wasn’t about being anti-customer; it was about being able to take responsibility for something you’ve actually done. And we hadn’t created what the users had created.

So, how does this relate to my opening story about AI agents? I see a risk where AI agents can create, well, ‘sloppy applications’ in a way and on a scale that could become very extensive. If users do this within an organisation, for the organisation, and then move on to a job elsewhere, the organisation is left with an application that is potentially very hard to refactor, configure, or change because no one knows what that employee actually did. It’s quite likely that such an employee is a ”single-point-of-failure-person” — someone who cracks the code much better than everyone else.

This could have potentially dire consequences for businesses that suddenly find themselves with a whole string of possibly broken tools. I don’t know if we really want to see a future of ‘SharePoint all over the place,’ so to speak.

I wonder what you think about this development and how you see it — how should we handle it going forward? I believe businesses should be very careful about allowing app development driven by individuals in a stochastic and spontaneous way across the organisation. We cannot simply replace IT professionals—the traditional coders—with AI agents that are fed with spoken requirements and needs, to bring tools to life. I think we will deeply regret it the day these systems require more thorough maintenance.

2026-01-27
Choosing language, the continued pivoting of me, myself, and more

Since I last posted, I’ve been struggling with my ”marketing overhaul” as part of my business model pivot. I actually haven’t been feeling very comfy about the path I chose, eg. trying to swiftly create some smart posts and articles on LinkedIn and start to send InMails on LinkedIn as well, to possible prospects.

I actually got stuck in some sort of creative process I haven’t defined fully yet. Wondering where to go right now is possibly a part of the journey I’m on that should be to carve out “a strategy” if one prefers to use that term.

I’m beginning to wonder if we shouldn’t treat “strategy work” as something deeper and more of an introspective thing, at least when it comes to what one as an individual needs to do in order to – well, there we are – in order to actually find a pace and a way of life one truly can enjoy. Enrolling in assignments with absurd conditions and expectations is neither fulfilling nor satisfactory in the long run. It might as well just be better and more comfortable to strive for – employment…

What sparked my thinking in this possibly not-regarded-as-so-prosperous-and-successful-in-terms-of-monetization direction was a written piece of Maarten Dalmijn, a Dutch guy writing about, hmm, product management and value creation, I guess you can summarize it to. I’ve been following him from his earliest days of writing, and reading this essay was an enlightening moment for me.

He writes so wisely about why easing the grip of climbing the career ladder when you really don’t need to, could be a better way for finding a better balance between work and life and everything in-between. I try to have in mind though that Maarten has a track record of maybe 10 years of writing on his subject, so he sure has an advantage – and that asset of making an impression is important to nurture.

I have also reconsidered the change of language to use when writing and, hmm, marketing myself. I actually find it easier to express my thoughts in English, and there is a fact that I have preconditions for better reach with natively created texts in English. It’s a hard truth that Swedish is a niche language spoken by a few cave-living creatures up in the north… It also makes a web page much easier to maintain than having to implement multiple language support. So – I will re-translate my “marketing parts” on the web page again, but this time with a better clarity on who I am and what I want to deliver for potential customers (though the value proposition messaging actually has been remarkably consistent during the years).

I will also try to cross-post as much as possible. I have decided that this site is my source and posts published here will show up, possibly slightly modified, on LinkedIn as articles and on Substack and I will try to evaluate where the best engagement is achieved, though the underlying drive force should be just to get everything out that is boiling in my head.

So, in order to follow the promised route about writing about strategy work, how it can be done effectively, and with myself as the example, here comes a first sentence:

The first thing to do when deciding to actually dive into your strategy work is to perform a diagnosis. This is one of three pillars in what Richard P. Rumelt points out as “the kernel” of the strategy (I have adopted Rumelt’s theories about good strategy work that he describes in the book “Good Strategy, Bad Strategy,” and it is this “framework” I will promote onwards).

Simplified, this first step is about asking oneself “what is going on?” And by this, identify the problem that is most prioritized to solve. For my own part, this is quite clear: I need to get some sort of cadence on my revenues again, and writing this is a small piece in the puzzle I’m about to solve.

For the enterprise, be it small or big, this might be a tough start. And that’s where one like me can come in and make a difference. It’s important to bear in mind that I will get you to dig into your (and your organization’s) knowledge and lift your already made experiences up to the light so your business actually can benefit from knowledge hiding in people’s minds. With that said – I’m not the expert. You are. My expertise is in how to get you to release your (business’) potential.

2026-01-13
Strategiarbete – ett aktuellt exempel –
Som ett led i att förklara vad strategiarbete kan vara tänkte jag ta mig själv som exempel.

Ända sedan jag startade min egna konsultfirma har jag egentligen huvudsakligen gjort det som man gör som anställd i ett bolag eller organisation. Jag har svarat på annonserade förfrågningar med ansökan för att förhoppningsvis bli antagen på uppdrag som passar in på mina erfarenheter och förmågor, detta i konkurrens med fler – -> många andra som också bedömer sig som kvalificerade.

Med tiden har vi blivit fler och fler som slåss om en kaka som i någon mån krymper och växer i takt med konjunktur- politiska- och andra omvärldsliga svängningar. Fundamentala marknadsekonomiska spelregler säger att med den spelplanen och avtagande fart på ekonomin sjunker priserna samtidigt som utsikterna att bli antagen (ytterligare) minskar.

Det är i det här läget man är skyldig sig själv att fråga om det inte är dags att ändra på någonting – att börja jobba med sin strategi.

Sagt och gjort: jag har dragit slutsatsen att jag borde gå från att vara en timdebiterande resurs till att vara en leverantör av bevisat värde (det går självklart att bevisa värdeskapande i timdebiteringsformen och skall så vara, men ofta tenderar värdeskapandet i den traditionella resurskonsultaffären att komma i skymundan av arbetet med att “fylla luckor”).

Det jag levererar ska vara tydligt paketerat så man redan på förhand kan få en uppfattning om omfattning, kostnad och effekt.

Som en följd av detta har jag behövt lära om och lära nytt – jag behöver börja sälja. och då menar jag sälja enligt den professionella definitionen av försäljning: att ge råd och rekommendationer som ger kunden ett bevisat värde.

Utmaningen jag tagit mig an är så mycket mer omfattande än jag kunna göra mig en föreställning om och den skapar en mestadels obehaglig känsla av osäkerhet. Men kanske den osäkerheten i det långa loppet ger mer tillbaka än den falska säkerhet som en tillsvidareanställning, eller långa, svårjobbade uppdrag ger. Du vet ju aldrig på förhand när det plötsligt är dags att packa ihop och gå hem, och du får inte alltid reda på orsaken till varför det blir så.

Här börjar min resa mot – tja, något annat än det tidigare i alla fall. Saker jag hittills gjort för att öka mina chanser att lyckas:
- Gått en kurs i hur man bokar möten genom kalla samtal
- Riktat upp en väldigt ostyrig hemsida som aldrig haft ett vettigt innehåll för att marknadsföra mig (här återstår MYCKET, men nu talar den i alla fall om vad jag gör (vill göra)).
Vad som återstår:
- Att lära mig grundläggande prospektering (ett mycket utmanande område)
  - Omsätta ovanstående i handling (d.v.s. identifiera målgrupper och därigenom s.k. suspects – förmodat intresserade av mitt erbjudande)
  - Skapa och bygga min hitlista, d.v.s. en lista över de personer jag tror är intressanta att kontakta
- Att öka min närvaro på sociala medier, där LinkedIn är prioriterat
  - I detta lista ut hur algoritmerna jobbar för mig istället för tvärtom
  - Posta och framförallt interagera
- PRIO 1 – men ändå inte – att börja ringa kalla samtal
  - Här behöver hitlistan vara framme
  - Sociala medier behöver kunna bekräfta bilden av mig (well, but…)
- UNDER TIDEN: skapa koncept, beskrivningar och underlag för mina produkter.
  - Presentationer
  - Info på hemsidan
  - Material till sociala medier
- ALLT ANNAT:
  - Tiden som jag behöver ta tillvara på ett ansvarsfullt sätt, mycket mer av min arbetstid är numera ”min tid” mot tidigare ”kundens tid”
  - Alla hjärnspöken som sitter på mina axlar och skriker i kör: ”DU KOMMER ATT MISSLYCKAS, DU ÄR INGEN, DU ÄR FÖR GAMMAL!” Och så vidare. De här behöver på riktigt hanteras med fast hand och en stor dos energi och envishet. Frågan är bara hur?
2025-12-18
Vad är egentligen en strategi?
Ägnar du dig åt strategisk planering? Har du en strategi-plan? Då är det dags att tänka om. Varför då? Jo för att en strategi är något helt annat än en strategi-plan, även om man kan lista åtgärder och aktiviteter som behöver genomföras, med ansvarig och tid då det ska vara klart med mera. En strategi handlar oftast om en förflyttning från ett tillstånd (nuvarande) till ett annat (önskat). En strategi bygger på vilja, antaganden, visioner och mål och den rymmer osäkerheter man måste hantera under resan man gör.

I företagssammanhang borde det handla om att göra något för att skaffa sig en fördel före medtävlare (konkurrenter), så att man säkerställer fortsatt eller ännu hellre ökad konkurrenskraft och därigenom ökad tillväxt.

I en offentlig verksamhet borde det handla om att exempelvis förändra hur man lever upp till det som är ens uppdrag, där det överordnade syftet alltid bör (ska?) vara att tjäna medborgarna på bästa möjliga vis.

Vad är nytt i det här då? Undrar du förstås – det här har vi ju hört så många gånger förr?

Ja, det kanske låter konstigt, men de flesta företag och organisationer ägnar sig gärna åt ”strategisk planering” hellre än riktigt strategiarbete, för det är mycket bekvämare än alternativet, det man borde ägna sig åt på ledningsnivå.

En av de bästa definitionerna av begreppet “strategi” har Roger Martin formulerat och den kan man ta del av här. Den lyder som följer:

Strategi
“En sammansatt uppsättning val som som placerar dig på en spelplan du väljer, på ett sätt som gör att du vinner”.

Strategin har en teori: den förklarar varför du ska vara på den spelplanen du väljer, och vidare hur du, på denna spelplan, ska vara bättre än någon annan på att betjäna kunderna på den spelplanen. Den här teorin måste hänga samman i alla sina delar och den måste vara genomförbar. Du behöver kunna identifiera aktiviteter ur den för att det ska vara en bra strategi.
Strategi

Verkliga kunder är kunderna

Du kan inte kontrollera dem

Du kan inte kontrollera intäkter
Plan

Du kontrollerar kostnader

Du är kund

Det är vant och bekvämt
Låter det här krångligt och abstrakt?

Det finns metoder för att göra det här mer greppbart och enkelt att jobba med. Jag kommer att förklara hur i kommande poster.
2025-12-12
You must transform to the future of work!! – or do you…?

AND I CAN SHOW YOU HOW!! – or can I?

The trend is strong, there is a career advisor (or COACH – how I have come to dislike this word more and more) behind every corner, eager to sell you his or her advice. The only thing that seem to differ is the price tag – some are selling a fairly cheap bullet list for you to check, step by step, and thy future shall be bright and prosperous. Others sell qualified courses and programs for more or less hefty sums which in themselves can act as a strong motivator for you to actually do something for yourself, eg. for gods sake, use the expensive toolbox you just bought. And of course, there is a myriad of levels and variants in between these extremes.

I must emphasize that I have the deepest respect for these people (well, most of them) that are getting themselves out of their comfort zones, and I think it is fascinating how many of them who seem to succeed (of course, the less successful majority is sorted out by the algorithms, but anyway, er).

The pattern I see in this I find interesting, but it’s nothing new. It is that business areas that are the most prosperous ones are the ones selling hope. We have entered at stage in history (yet again maybe) where the pot filled with gold at the end of the rainbow is the most grateful or easy thing to start selling, which means that being a coach who sells prosperity recipes becomes some sort of meta-coaching, since supporting the marketeers marketing is very common these days when every one needs to (or do they?) start their own business, thus being in the need for advice, right?

This pattern is common in dire times with lay-offs and distrust in growth forecasts, and it is probably virtously reinforced by the SoMe penetration into our very genomes.

My problem in this, without making this to a cry baby post, is that I am doing my thing in a high-competition market, where thousands and thousands of skilled people are offering the same thing as me – high-end (er…) consulting services, preferably to more or less large public adminstrations and private enterprises, and this market is owned by them brokers who are offering their customers a filter function in order to push prices down and to cut a nice commission on just being – a broker.
This, in combination with me having my imposter syndrome, and a not clearly niched competence profile. makes it hard find someone who actually can ordinate me a clear path ahead where I can get prosperous and get an even and nicely leveled revenue stream. So, my analysis of the flourishing coaching market is: it’s not for every one, it’s more for the (hopefully becoming) seller than the buyer, and I’m not one of these.

Another problem I have with this is a severe bias towards doubt when it comes to salability – my thoughts most often revolves around “nobody can buy that, so stupid can’t anyone be“, about offerings I stumble over, but the fact remains – people buy crap, and they’re happy with it! So why shouldn’t I be able to sell my own value, but towards totally different markets and through totally different channels I’m used to?

THAT is my challenge ahead, and now I have time to do something about it, before I pop out in a new period of fighting for a (too poorly) paid assignment. I must just find out how my track record can be converted into an offer you can’t refuse, owned by me, giving you maximum value. Time for a change, and to actually start doing it. Stay tuned.

2025-02-12
Web3 and all of my questions, #3

There is obviously a dividing line between integrity and authenticity when we talk about creating value based on Web3 technology. I’ll see if I wind up my own tail in trying to elaborate on this (for me) quite unclear topic.

Cryptocurrencies, distributed ledgers, DApps etc. built on a blockchain has this quite odd property – they leave the users information wide open for all who look into the database of the blockchain. This is by design and quite inevitable as I have understood it, and it was revealed for quite some years ago as a part of research written about in Wired (it’s a really well-written long read, highly recommended for those looking for an introduction to the crypto world).

This reveals a conflict between wanting to claim authenticity and wanting to have integrity. I visited a webinar a couple weeks ago where a Swedish web3 community had invited to a session around web3 application for corporates. I realized there and then that one of the first questions a buyer representative on an enterprise is going to ask is “how does your product/technology comply with GDPR*?” And I also realized that if you don’t have a clear answer to give instantly on that question, the buyer’s not gonna buy (or even consider to further think about it. Said and done, I thought I should be the smart one in the virtual room and ask about the lecturer’s view on this. And yes, it became clear for me that this isn’t an obvious thing to solve. You can of course build protection mechanisms in your overarching logic, but it isn’t necessarily an easy task, since this mechanism need to follow your info through the blockchains journey through the nodes.

Another question to think about in this context is then – is it even desirable? Do we really want to hide our personal data that we have uploaded in the blockchain? Isn’t this one of the purposes with the cryptographic technology – to prove that we really are the one we claim to be? And could it even be that we need to redefine what personal data is, when web3 use gain a wider traction, or is it even like personal data is personal data covered by GDPR* in one application and not in another? Is maybe GDPR* not be applicable in certain future use case scenarios? In some use cases it might be more important for me to prove my authenticity than having my integrity secured, or?

This leads me to an analogy regarding surveillance and me being the one saying “I don’t care ‘cuz I have nothing to hide”. Could it be really, really bad in a long term to claim authenticity through blockchain-ish footprint from a surveillance perspective, if the surveillance structures start to use my wide-spread, wide-open authenticity information against me?

A possible branch on this topic is to analyze fraudster scenarios and how to block them, a topic possibly being another factor the buyer of web3 development will ask questions around. Having preparations for this in a product development startup quickly becomes a hygiene factor in order to build trust towards the corporate user.

*)GDPR here taken as an example of an extensive and very adopted regulatory framework, with the awareness of many other frameworks existing globally.

2024-03-04
If I told you that your documentation sucks, would you agree?

The real challenge when discussing documentation quality is that it is a topic with so many layers, bottom and dimensions. But I can tell you the following: maintaining documentation is almost an impossible task, when talking about quality and conformity, if you don’t do it right.

It’s also hard to sort out what one actually mean when talking about documentation. In my world, the most obvious type of documentation and actually where I should start a “sifting project” if I got the assignment to do it, is in what many often, quite nonchalantly calls the “operations management system” or maybe “business management system”.

This is most commonly residing in a folder structure on an internal server and consists of a more or less large chunk of word and excel files. Some organizations are that bold so they actually buy a system or a service to use for this, but many, if not to say most, organizations rely heavily on an implementation of Sharepoint that someone purchased years ago, maybe a bit clueless about what to use it for.

The really minor version of the business management system is the word file in the small company that the employees in an ideal world receives printed in their hand at their first day at work. In Sweden often called “företagshandbok” or “business handbook”. Here one should be able to take part of decisions made by the firm’s boss(es), that are general and not subject for change that often.

But what happens when new or changed conditions arise, and new decisions are made that might make the printed statements obsolete and possibly even contradictory to what earlier has been communicated? This is a phenomenon valid for all and everybody, regardless of size of the organization or pace in information changes. I should say that in the very same moment that a new decision Is made, or a circumstance popped up making writings inaccurate, the risk for trust within the organization start to erode. It might not be a big issue at first, but if the maintainer och the information don’t swiftly inform everybody affected by the change that new information is available, the risk is that someone find out and take advantage of it. Within a shorter period of time one realize at first, the respect for what has been decided lessens, and so does the attitude towards personal responsibility and engagement as well. This will do daily management more cumbersome to perform and time for information maintenance will be taken for handling errors and corrective measures.

“But this is obvious!” say the initiated reader – “why even bother take time to write about such things that are always ongoing??”
Well, maybe just because this is always ongoing, in far too many places. This also hampers the communication efforts and erodes the value of communication not seldom critical for the business in question. In a little bit longer turn it affects the profitability (or in a public service, level of value creation and effective use of taxpayers money.

So, how should one do to get around this problem? I’m convinced that managers on all levels need to be continuously fostered in how to communicate. Because the communication culture is so firmly connected to the accuracy of what is communicated. I dare to say that if you manage to make everybody aware of the natural law of information, stating that:

If one don’t have information, it is not possible to take responsibility,
but if one have information, it is not possible to not take responsibility.

Add to this that the information must be accurate, and you have a solid starting point for your work with communication planning.

An additional bonus to this is that if you nurture a communication and information aware culture, overbody involved will be interested in and prone to put requirements on correct information to be correctly communicated.

And this, is one of the most overlooked things in organizations. Now and everywhere.

Technical documentation, often managed within some sort of Configuration Management Process, is partly a bit different though related. I will come back on that one in a future post. As well as the hurdles with how to actually get the organization informed for real. And that’s even one more future post.

2024-01-24
The ‘start from a blank paper’ curse

It aint what you might believe at first – a super-trendy writing about how to start blogging. It’s far more boring than that. This piece could also be headlined with something like “How to overcome the lingual glitch between IT and the rest” (though I realize I don’t have any clear answers, after reviewing this mess).

This reasoning might seem a bit over-due, old school or even obsolete in the era of furious Product-Management-with-an-agile-foundation, but it will never stop being relevant. Why? Because old truths are boring but often more persistent than we actually want them to be.

I will elaborate on one of the most overlooked phenomena that has existed even since human started to build things that in some way does human work for her – namely managing of requirements. I find it kinda strange that this discipline so often is regarded as a certain discipline, hosted outside a production workflow och outside a development project and populated by specialists that is regarded as a really special sort of nerds. The competence field QA is also often perceived as a bit self-generating and my experience is that it often is slipping around above or around the project or maintenance teams it is supposed to be integrated in*, similar to “the process team” that makes process management a work on its own merits, often regarded as self-generating as well.

From time to time I have been involved in discussions with business representants and in the context of trying to understands the needs and what problem they want IT to solve. Many times we have been sitting with an existing solution that fits the needs ok but not fully, and trying to improve functionality already decided and designed by a third part, the vendor of a system, may it be a cots, may it be quite a specialized product (in earlier days often named service, but product is a more popular term nowadays, yet another thing to explore in a future post…).

A repeating thing that has showed in these contexts is that the business side often have difficulties in formulating requirements so they are easy to digest for the IT people trying to technically solve the issues. Once we took it so far that we arranged educations for the business stakeholders, eg. mostly process leaders (might today be replaced by Product Owners), where we let our very dedicated and skilled requirements analyst teach requirements management to the participants. This turned out quite well for some time (not that long that we’d wished though), and lead to a little bit deeper understanding on the business side for the need of a common language when having the specifying dialogues.

BUT – the error I think we made then was to assume the starting point too late than what we should have** – because we didn’t explore the need for the requirement to occur in the first place. Business needs is the focal point one should start looking into instead of starting a change or request journey with trying to state a requirement that might be quite intangible if the needs aren’t clarified. I have seen agile profiles in different feeds emphasizing the need discussion, but I have never seen it being more than a fragment in the never ending flood of talk-about-how-to-work platitudes. This should be a success factor in both easing the need for translation but also a possible lever for the business side to actually take more active part in the early phase of a change tickets journey in the code-crunching machinery. It has also the potential of easing the often (always) cumbersome with prioritizing a backlog, since it should be much more obvious how needs are weighed towards each other than bad formulated user stories or features with unclear business value. It also has the potential to give a clearer definition of done, if you originate from the need instead of a lingo-feature description.

BUT – isn’t this already what all agile how to’s and agile descriptions always have told us in DoD and DoR’s explanations??

OF COURSE – I’m not trying to come up with some new fresh ideas here, I’m just (as always) trying to point out what already exists.

BUT – try, just try to give a business representative the explanation of DoD found here of even DoR found here, and you will get this “do I dare to question this mumbo-jumbo without being classified as an idiot” face in return. We really do need to be able to talk about needs (and in second-hand requirements) with the business side with being so centric about the IT-side lingo which is held so dearly by too many.

Tying the ropes:
Regarding the headline of this post: I somehow feel that I need to get back to this in order to tie this story together. One of the most common and I guess classic mistakes organizations do when it comes to management of requirements is the silly “You just can start from a blank paper” prompt, given by IT to business. It is often ditched quite quickly, since everybody knows that they need some kind of facilitation or guiding, because the present state is needed as input value, as well as different conditions and constraints that limits what actually is possible to describe if the user story is supposed to be meaningful and valuable.

For reference:
The explanation of what a user story is supposed to be is actually more or less good, but often overlooked and not fully embraced (or understood, or correct interpreted) by all in the processes, making it necessary to reflect over when uncertainties are spotted.

To be continued:
*) The QA experts should have more of a more tangible, facilitating role in the organizations they serve than they have, since their traces most often is a trove of hard-to-answer questions in the WoW-section of the endless Confluence library – for every team to invent and solve independently.

**) This urges me to write about the real life cycle of a change or new-feature ticket in a teams workflow. Will do this as soon as possible.

2024-01-24