Hacker News Reader

Comment by fhd2 | Hacker News Reader

Don't agree with everything, but the opening for sure:

"People Who Make Software Happen (you may know them as “programmers”) should have the option to progress their careers without leaving the code face."

I was promoted to CTO of a quickly growing company some years back. At some point I had so many offsites, strategy workshops and generally low value meetings (that the other C levels loved), that I got somewhat out of touch with what's actually going on in the code base and with the people. I was both frustrated and ineffective. Ever since I've made sure I spend roughly half my time in a CTO role reviewing/writing code or pairing.

It's not about all good programmers being managers, though they should be given the opportunity if they want it. It's about all (technical) managers being decent programmers.

View on HN

That was on you though, and by the sounds of it you realized that and fixed it. When you're a C-level you're expected to use your autonomy and agency to say no to things, and if people need you to be there (eg strategy meetings that need tech input) then they should have to work to your priorities.

No one above senior dev level has too many meetings. The issue is always that they say yes to all the meetings they're invited to. Realizing that you're allowed to say no is a critical part of leadership. Possibly the most important part...

Absolutely true, it was nothing but my own failure to not follow whatever "best practices" (how I dislike that phrase) others talked me into. It's lonely to be the only technical guy in the C suite of a tech company, but that's the job. And it's important - I've seen what happens when there's nobody there.

What surprised me when I became a manager was how high the variance of the workload was. Some days (or even weeks) I have very little administrative/communication work to do. Others I'm doing 10 hour days to catch up.

Since I don't know when I will be swamped next, I'm hesitant to take on technical work lest I block someone else. How are you handling this? Have you found a way to smooth the admin/comm load?

(One advice is was given is "do only low value technical work" and I've tried this but it's just not satisfying enough to keep me engaged.)

I either do low value work or, most of the time, I support others.

For the juniors on the team, I make myself available for pairing so I can help train them. For the seniors, I help them by writing documentation, reviewing their work and making sure it's aligned with where we want to go (you can call it architecture but I don't like to throw that word around), or help out by resolving disagreements. Or whatever they need really. Not all of that stuff is technically "code", but to me it's not primarily about writing code myself, it's about being constantly in touch with the code base in some fashion or another.

I also delegate organisational work to those on the team interested in it - I very rarely run a meeting or drive some work, I just fill in the cracks where nobody else wants to do it.

The main trick is probably that we maintain a highly asynchronous communication culture - which is not for everybody and non trivial to establish and keep. But if it works, it really works.

I really like this approach - in some respects I think managers should be serving their subordinates. I've just recently become a manager of a data team, having previously been a data person myself. I find myself with very little time to do anything technical, and envy my team members when I see them doing technical work.

Do you have any advice for a technical person newly turned manager? Anything you wish someone had told you when you started as a manager / leader?

Well, I'm thinking about trying consulting so I started to offer free consultations to get better at it - see my profile.

I can't think of a lot of generic advise: Sure, people I've talked to over the last 13 months of doing this face more or less the same problems, but how to best deal with them depends entirely on their situation, the people they work with and their own personality and skills.

One of the most eye opening things I've learned about is Cynefin from Dave (!) Snowden - wish someone had told me about it when I just started.

On the more generic side, I think the most important thing I wish someone told me is to not be _too_ humble, to trust my intuition and experience and be proud of my brand of management, not apologetic for not doing things the way somebody else read they're supposed to be done. Depending on your personality, I might as well recommend to be _more_ humble though - the balance is key for me.

> I think managers should be serving their subordinates

This is totally what I think about managers of technical staff (and not "in some respects"). It's the subordinates that are doing the production; managers are lubricant, whose task is to ensure the production staff are maximally effective. Without effective management, production staff operate at reduced efficiency. But without production staff, managers are completely useless, and might as well be re-tasked to work as coffee boys.

I'm referring to line-managers, not the executives who make business decisions. I know nothing of executive work, and I suspect there's not a lot of continuity between line management and executive work. And yet some line-managers carry on as if they're already three-star generals.

Oh, and for when I was running a larger ship with multiple teams, I would just focus on one team at a time, do all of the above there (with the other half of my time dedicated to more high level company wide work), then switch teams after a few months.

Probably not the best way to do it, and it might not scale beyond 230 people (since I never tried), but it's what I ended up with and it works well for me.

> I'm hesitant to take on technical work lest I block someone else.

Not the person that you replied to, but I would suggest doing code reviews as a non-approver, taking non-critical path tasks (documentation can always be improved) and writing examples/tests if appropriate for your system.

As a "senior" engineer, I believe it is my responsibility to code review as much as possible. It's the best use of my advanced knowledge outside of doing the occasional complex tasks.

As a manager, I would see my main job to, in this order 1) keep as much of the non-coding tasks off my ppl's plates, 2) code review when needed, 3) type actual code, 4) remember birthdays.

i don't like ppl with power over my employment and salary doing code reviews.

I had a CTO once doing random code reviews without knowing complete context. It was hard to contradict him or much easier to just accept the suggestion and move on.

Reply on news.ycombinator.com