Hacker News Reader

Comment by arcticbull | Hacker News Reader

I disagree completely.

Once you're in a management role, let alone a CEO role, your job not to write software. You defer defer implementation and architecture completely to your team. Your job is to hire and build that team and set high-level company direction.

The more power you have over your co-implementors' careers -- and the more junior they are -- the less comfortable they are standing up to your architectural or technical decisions. This stifling of collaboration can cause you to make poor decisions you wouldn't otherwise, and creates an uncomfortable dynamic.

This is why I don't believe in TLM ("tech lead manager") roles, also, fwiw.

Wanna code? Do it on your own time, Tobi! :)

View on HN

You got the point provided that you are concerned about code quality. This might be an area where a CTO lacks skills over time compared to his developers.

Becoming a CTO myself within an 80 developers area, I found it invaluable to code infrequently still. It is quite simple: better decisions, better products.

To me, non-coding CTOs or most CEOs that do not understand Computer Science, it seems that they try to learn a foreign language by sending in their assistant to attend classes.

I mean this quite literally. My team can communicate to me in other terms and a different language than they would have in a simplified ELI5/KPI driven manner. And vice versa, I challenge them to think beyond day to day business.

It is not a lack of trust. It is about better understanding and better helping your team focus on the essential parts. And vice versa.

Generally true, but not always true. Shopify seem to be doing just fine with this model. If things change, maybe this model will also change.

I’ve only once worked under a manager who also coded, and I had extremely mixed feelings. On the one hand, he was a brilliant engineer who I learned a ton from, and who set a really solid technical direction for the team.

On the other hand, I was personally unhappy a lot of the time. On one occasion he pretty much tore apart one of my designs and I felt fairly humiliated (with reason, as a few other senior engineers confirmed in private conversations).

Did my design deserve to die horribly? I don’t know. The PR had already been accepted, but maybe the accepter was wrong. In any case it felt really crappy to be criticized so heavily by someone who in theory supports me.

You know, it's easy to be an asshole when you're brilliant. But that's why soft skills are important, especially in leadership roles.

I tried my best to be a supporting lead, everywhere i was in that role. I believe in leading by example, but i recognize the necessity to _let_ people do things themselves and not just hog power because "i know best". Let people implement imperfect designs. They'll own it, learn, and fix them in time. Your job is to lead, to give direction and not let total crap be put into prod, not keep people under your "benevolent dictator" heel.

I tend to disagree with the "live and let die" approach. Delegating responsibilities isn’t abandoning responsibilities and when deviation happens, getting hands dirty is good stewardship to me.

The main factor to me is the team size and subsequently the organization of said responsibilities delegation. My personal context sweet spot is around a 50 persons team.

There's also good and bad ways to give feedback. It's important to find ways to give honest feedback that isn't crushing your reports's confidence. It's more of a question of when to step in with an important critique that whether to at all. There are some pieces of code and systems that aren't critical enough or won't be stressed by a junior learning through a bad design decision. And critical system where you absolutely have to step in and make sure everything is in the best shape possible.

50 persons is a small organization, not a team!!

I agree about responsibilities part, however, if you don't let your people grow by simply vetoing the ideas, they won't grow. Discussing and openness to your subordinates' ideas is not a bad thing in my opinion. Letting people make proof-of-concepts and fail is not abandonment of responsibilities. Letting people implement their bad ideas in production is.

> 50 persons is a small organization, not a team!!

Well, I refer to the whole company as a team. This may be my SME bias :)

That's a sign of a good CxO, IMHO - thinking of the whole org as a team. Respect :)

As CEO or CTO, it;'s crucial you understand your business and if you're in a tech business, you better understand the tech to an appropriate level too. Coding can be a part of that

I believe in dog-fooding, using your own products. That holds for programmers and UI designer, who should use the software they build, but also for architects and CTOs: they should experience the effect of their decisions, and taking part in the design and coding can help.

Reply on news.ycombinator.com