The CEO came back at me saying that it should provide a lot of value to them, [..]. But these are all of value to the manager - Not the developer.
"It should help" is not an argument. It is a suggestion/command under the guise of what seems to be informative advice. But that doesn't prove that the CEO is wrong, it only suggests that he's not really addressing the concrete reasons for needing to use the board or addressing why the developers aren't using it.
Nonetheless, I can't exclude that this isn't just a case of developers refusing to do the administration that comes with managing their tasks.
I really don't believe the board provides any direct value to my devs at this point - and I don't believe I have read any literature explaining what value the developers should derive from the board other than being able to control the incoming tasks, which is dealt with at stage 1.
Your description is a bit vague for me to judge whether the above principle applies to your case, or whether you simply miss the benefit of (correctly) using kanban.
However, based on the following quotes, I do think you're glossing over the bus factor.
We have a very simple digital board which provided a lot of value initially because it got everyone into the habit of doing all the phases I wanted them to do before releasing something - but now they know it and don't need the reminders.
Bus factor: if your devs get run over by a bus tomorrow, will the newly hired devs understand the current state of the project? Nope. Because the old devs never wrote it down.
You are relying on the fact that when they leave the office, they will be back the next day to resume their work, and you assume they will remember where they left off.
And because they are only ever working on 1 - maybe 2 things at a time, keeping track is no problem for them. As far as my devs are concerned, they just want to know what is the task at hand, and then they will do it.
The same bus factor argument applies. What happens if the devs are sidetracked for some unexpected reason, and can only come back to their tasks after a significant absence? Will they remember everything? What if some of the devs don't come back and others have to pick up the work they left?
The hallmark for proper documentation (or in this case development tracking) is that you should be able to minimize the time loss from substituting everyone working on the project by someone with equal skill but lacking contextual knowledge of the project.
That's never truly achievable. Projects always rely on some form of contextual knowledge (even if only to understand the goal of the application). But you should minimize it to the best of your abilities, because you never know what might happen. Every person working on this project could drop dead or become otherwise unavailable at any time, and you need to prepare for that eventuality.
A reasonable limit
The thing is there there is wiggle room here. When we're talking about tasks that refer to small (<2h) bugs, I agree that the admin becomes a disproportionate hurdle, and the bus factor is minimized since at most you lose 2 hours of work.
But when your tasks include big feature sets, or tasks that take multiple days (or even weeks), the related administrative work is comparatively small and much more relevant. Without proper tracking, if the dev lands under a bus, you're going to lose all the work they did and may end up having to develop the feature from scratch (because it may take longer to figure out what they were doing as opposed to doing it from scratch).
A possibly bad Kanban board
However, it's still possible that the kanban board isn't actually tailored to the developer's needs, but only to those of management. Kanban boards can be useful, but that doesn't mean that every Kanban board is sufficiently useful to everyone involved.
A real world example with Jira's kanban-like board for sprints, used in my company:
My company has defined three swimlanes: to do, in progress, resolved (the fourth, closed is not visible to developers). But there is a complication: the "in progress" time is being tracked as billable hours to the customer.
The problem this creates is that we sometimes develop something, and it either gets put on hold or it awaits testing by a QA tester.
- When we put the ticket as resolved, it auto-closes at the end of the sprint. PMs are also liable to communicate the resolution to the customer even though the problem is not provably solved yet. But even if you ignore the auto-close feature, "resolved" does not accurately reflect the state of a ticket that "should be tested".
- When we leave the ticket as in progress, time keeps ticking and billable hours become incorrect.
The only other option is to put it back as a todo item. But at the end of the sprint, management then comes and asks the developers (not the testers) why they didn't pick up this ticket. And when the developers respond, management explains that they don't care about the internal workings of the desk (testing is considered part of development), they just use this to keep track of the state of tasks so they can update the customer.
The problem here is that the board does not allow for accurately reflecting the state of things, which means that it loses all purpose for developers, who are now forced to remember the real state of things while also having to update a board that is (to them) incorrect.
This is just an example, and a very specific one. It could easily be resolved by adding additional swimlanes and ways to calculate billable hours.
But it highlights an often recurring problem when developers reject using a system that management wants them to use: its intended usage benefits management, but not the developers.