[ingmarheinrich]

It's a bit similar to what I'm thinking about right now. I started my career close to 20 years ago, coding dynamic web pages (yes, I worked with php3), and unintentionally broadened my skillset into something like a CTO skillset for specific environments - I never was a really great coder, so I'm not suited for the lead-developer kind of role in an early phase startup.

Now I'm losing more and more interest in "core tech". While I find infrastructure, performance and scaling still kinda interesting on a rather abstract level, I find it more and more enjoyable to work with "people & processes", so: How do people collaborate within an IT department, how does IT collaborate with its stakeholders, how are the roles & responsibilities structured, where are the frustrations, what can be improved, how do we scale the team.

I've been doing this as a freelancer for almost three years now, and I had just two large-ish projects (about 6 months each). Problem is that both projects were started because management thought the problems they were facing were "the IT's fault", so I was hired as an interim CTO to "fix the IT". Management had the impression that I would look at the code and improve it, and then everything would be fine. However in both projects I discovered there were various severe dysfunctions that didn't really have anything to do with what the IT produced.

So staying within the jurisdiction of IT seems reasonable, but I'm also thinking about leaving it completely to become a general "organisational coach". But at the end of the day, I have no idea what to do, since right now it's hard to find clients, since my communication is rather incoherent, and people don't really understand what I have to offer. As soon as I say that I won't even _read_ code, they think I'm completely useless.

[le-mark]

> However in both projects I discovered there were various severe dysfunctions that didn't really have anything to do with what the IT produced.

This is very common and it's not funny, it's tragic. IME the problem always comes down to personalities in upper management. They're incompetent, and give rise to incompetent teams.

I once worked with an old mainframe programmer who had re-created himself to be a process evangalist by going off and getting a ph.d from some no name univerisity. When I worked with him he was hired as a senior business analyst. I was very intrigued by how he perceived his role and value add. He used to say his job was to get the right people in meetings to talk to each other, and they would make the decisions. And that's all he did, organize meetings, for the full year he worked there.

In the end he was very adamant about not taking on any other responsiblities and was fired. Luckily, the company was smallish and wised up. Looking at his linkedin, you see a similar pattern, 6-12 month gigs all over town. Maybe he'll land in a suitably Big Dumb Corp someday. My take away was, for that type of role, you really need to DO something. Banal, I know.

[ingmarheinrich]

First of all, getting people together to talk is not doing nothing. It's getting people together and talk. There are companies/departments where people just don't talk to each other anymore, or not about the right things, because many things are so bogged down that people don't bring them up anymore.

Ok, now while I'm typing I see what you might mean: Of course in a management role you actually have to actively "facilitate": You have to challenge things that seem to be stuck, you have to offer solutions by comparing your experience with the situation at hand. Some kind of an "organisational coach with focus on IT teams". But this wouldn't be a permanent position but a freelance one, and 6 months seems to be a reasonable time for an IT team (and its stakeholders!) to resolve a lot of issues and to be able to flourish on their own.

Having the team decide on architectural matters isn't bad management per se in my opinion. At least having most of the ideas - of course management is responsible for the decisions, but if the ideas come from the team, the developers usually feel way more appreciated, and the decisions are supported way better than those that "come from above". But also, management has to facilitate: Have the team explain why they want to do things a certain way, have them lay out alternatives, and challenge their ideas with your experience.

That's just my understanding of an IT manager: You're not a manager because you were the best developer, and so you were promoted - changing into a management role is NOT a promotion, it's taking a different career path, doing a different job. So to my mind an IT manager should not be a lead architect who has all the great ideas, and the team works them off. He's a Servant Leader who helps the team to be the best team they can be.