Over the years, I've found the most productive way to go is for the leads to share the responsibility, with input, tie-breaking, and the occasional veto by a technically literate project manager ("yes that sounds neat but it's antagonistic to our business goals so pick something else").
Architecture as a responsibility, not a title. It's harder to prioritize - there is no point person - but the payoffs if you do manage it are not to be sneezed at.
You trust people with skin in the game, who suffer along with you when the 'right decision' results in near-term pain. Some guy who barely writes code lecturing you about how you're doing it wrong? Nobody respects that guy, except to their face, when the bosses are around.
Take a ticket and deploy a solution to production. Such a rule takes peoples' heads out of the clouds and connects them with reality. Time and again, I perceive programming as a humbling experience.
I actually don't think half a day is nearly enough. BUT I also don't think that this needs to happen every week. Sometimes, there are periods of exploration and discovery - whether it be with new technology, new approaches within the company, or coming up with some more grand long-term vision to align the tech org towards.
However, when you're out of discovery mode, you need to be in the weeds writing prolific code, feeling the impact (good or bad) of your decisions and course correcting as you go. Moreover, you need to see how other people are feeling about your decisions. At the end of the day, you're working in service of them, helping a team, teams, or the overall tech org to be successful, which in turn will (hopefully) help make the business successful. Often times when I hear disparaging stories about architects, they aren't fulfilling that tenet - either because they don't have the skill to do so or they believe everyone else just needs to keep up with their brilliance.
I've been in too many situations where once the "architecture" was done, the project was to be tossed to some engineers while I work full time on something else. Unless you have some awesome leads that are in lock step with the architect, then that is a recipe for disaster.
The last thing I'll say is that everyone writing code is an architect. You're inevitably making decisions about the way things will be built, no matter how small. Virtually all software has an architecture - but too often it's incidental architecture rather than intentional architecture. Make conscious decisions about your code, reflect on those decisions, and keep an open mind - whether you're just starting out or have decades of experience.
This is a key point, but People might say "software is eating the world", but many organizations are not yet at this point. You can find modern healthcare or pharma organizations which are doing real engineering, but this is still the exception in many places.
What you find is organizations which can still survive on old technology and the processes which got them there. At some point modernization will also have meant outsourcing tech to the lowest bidder. You have an organization which is unfit for engineering in the current state and the architects are more familiar with managing this process work than doing what folks here would consider real engineering.
These organizations are ripe for modernization. They have aging tech and tenured teams which can only make very incremental improvements. As market conditions change, leadership may decide that they really need to make changes and these people will be cast aside. It's a somewhat double-edge sword because the old folks do have value in that they understand all of the details of their business processes which are apparent to even a really good engineering and product team replacing them.
The problems they want to solve require an engineering culture. There are no ways around that.
Like many hospitals, they've been hit hard by COVID-19. They recently announced golden handshakes for people close to retiring. It's painful for people now, but hopefully someone will see it as an opportunity to change the culture.
Even an out of touch manager can contribute to and/or observe the state of the code base while pairing with someone who works on it full time.
Truth. At every job I start, I manage to say, "Wow, I am way behind these guys on what I know." That's not a bad thing because it's pushed me to grow.
I have worked all my life in organizations producing software, never once was this true: there was always some level in the organization were people stopped all programming tasks (with all the bad side effects of that, that the head does not really understand the capabilities of the organization, what is feasible and what is not...).
I agree with you, I just have not had the luck to see it.
You probably mean on average, and yeah, I agree. But the literal reading of programming half a day per week feels horrible.
Partially, because the organization is a lot bigger than 1 man. I'm working close to my home in a company that respects work/life balance. Pay is reasonably good, especially as i don't have a multi-hour commute anymore. I wont be fired from one day to the next. I'm pretty sure the organization is all in all doing good work helping people forward. There are a lot of people with great technical and other expertise. Also good, nice, solid people. My work is appreciated. I have a good amount of freedom. There are enough layers of management that I don't have to deal much with the architects.
And the weird thing is, it is working with him as head architect. He is the kind of person that can sell anything to anyone, even turning around people that were disgusted of him a few months before. I'm pretty sure he makes technological choices by reading Garner slides and doesn't really understand what they are or what the results will be. Even so, he manages to get things moving and agreement built in a very complex organization. He causes change, others give that change a usefull direction, and the net result is, well, usefull results. Strange but true.
However, it sounds like your architect is more of project manager than an architect.
As it should be, I'm an architect, worked for Central banks (equiv of the FED), working for crypto startups, and also medium size enterprise... I don't respect architects that can't "do". That said It's an important function IMO.
Over time, with Agile and I as I worked in smaller companies, I ran into fewer architects, and the people I did meet were basically senior-senior devs - People who had been at the company for a while. It was more of a reward and respect for them. Same as before though - really good devs.
This article is good at narrowing the requirements, but I think it's still a bit vague and abstract for this age. My last job, a large hospital, we had an architect that I constantly butted heads with. He hadn't coded in decades (not sure if ever) and was obsessed with picking technologies based on the wrong criteria. He thought of himself as this high level, European academic-type that was too busy with big issues. This style basically made him out of touch with anything going on in modern tech.
He had a knack for picking old, dying technologies. I got a particular kick out of sending former colleagues the post here on HN last month about Apache Drill, which he advocated for, being discontinued.
My argument to our CDO was that if he walked outside and yanked any senior engineer from Amazon, they could do a better job than this guy. His job, picking tech, is less important these days with Agile and modern applications, well, architecture. From what I've seen in my career, the expectations for an architect are far more "hands in the dirt" as time goes on.