81–90 of 245 posts
Congratulations on getting published! I've bought the book and read until the Delegation chapter. Up until now I find that the topics are interesting and the writing is very direct and unpretentious which I appreciate. I also like the approach you took of wrapping it in a story, I think it makes the topic a lot less dry. At the same time I feel that it doesn't go into the detail I would like. For instance I feel that…
If anyone is considering moving into engineering management, you'd do well to look not just at the how but the why . If it's for status/salary rather than the change in nature of the work be very careful about making the move. You need to really want to manage and develop people (with all the idiosyncracies that real human beings come with!), and to communicate, co-ordinate, and delegate for a living. Some will love…
What is you are sick of the churn in the coding side of work and feel you have a decent understanding of developing software?
Do you like the idea of managing people, setting goals, spending time thrashing out plans with colleagues where your team, not you, will do the "work" - or are you simply preparing to tolerate all that for the extra salary and perceived career progress?
Honestly, it's not a trick question - you might really like all that!
Warning ... cynical, pessimistic viewpoint coming. Here is a pattern that I've observed over a few jobs that I've held as a developer at different companies. Wondering if anyone has any similar experience. The first line manager (only manages individual contributors) exhibits these characteristics. 1.)He used to be a coder, but that was a long time ago. SQL hasn't changed, so that's the bit he's drawn to when he feel…
OT: for those who have never been in leader/managerial positions: - Leading people is 1000x less fun than coding - Leading people makes your more money than as an avg coder - Leading people too long makes you lose your technical skills slowly - At some age and for most, there's no other option than leading, 'go or grow' - Leading bigger headcounts is comparable to competitive sports 24/7 and shouldn't be underestimat…
Congratulations on getting published! I've bought the book and read until the Delegation chapter. Up until now I find that the topics are interesting and the writing is very direct and unpretentious which I appreciate. I also like the approach you took of wrapping it in a story, I think it makes the topic a lot less dry. At the same time I feel that it doesn't go into the detail I would like. For instance I feel that…
That's kind of you to say that! Thank you. Can I email you to get some more of your feedback? What's the best way to contact you?
OT: for those who have never been in leader/managerial positions: - Leading people is 1000x less fun than coding - Leading people makes your more money than as an avg coder - Leading people too long makes you lose your technical skills slowly - At some age and for most, there's no other option than leading, 'go or grow' - Leading bigger headcounts is comparable to competitive sports 24/7 and shouldn't be underestimat…
OT: for those who have never been in leader/managerial positions: - Leading people is 1000x less fun than coding - Leading people makes your more money than as an avg coder - Leading people too long makes you lose your technical skills slowly - At some age and for most, there's no other option than leading, 'go or grow' - Leading bigger headcounts is comparable to competitive sports 24/7 and shouldn't be underestimat…
Earlier quoted context omitted.
I totally agree on your final sentence there. There's a number of things in that chapter you mention, and there's also material on managing upwards earlier on in the book. As an example of something I personally struggle with: what's the best way to have the rest of the company know what all of our teams are working on without A) going into too much detail B) being obtuse C) opening ourselves up for miscommunication…
You really hit the nail on the head there. It's so hard to give the right people the right information at the right time. I like the idea of the newsletter. Do you focus mostly on achievements, or discuss 'ways of working' as well? I'm really looking forward to the book, by the way.
The target audience for the newsletter was decided as "the busy exec". Not too much text, lots of gifs of functionality that we've built, etc.
There's some separate newsletters we do as well - there's a fortnightly "what's going on in the backend" one, curated by our infrastructure teams that's aimed at engineers.
Currently the general case newsletter goes to Engineering, Product, Product Design, and the exec group. We don't think it's quite good enough for the staff@ mailing list yet, but maybe we're just being over-cautious. It's really hard to get the balance right.
Earlier quoted context omitted.
That's a good question. I'm English and I work for a UK company. I had some reviewers at the 50% stage who were from European companies and they didn't say anything specific about this, but I'd be interested to learn more about the US tech scene being quite alien - I haven't experienced it myself.
Well, I guess I assumed wrong then! =) And for me as a Swede the most alien thing for me is the "lone genius startup"-thing (that probably is very over represented/emphasized here at HN) where developers work for stocks(?) and hope(?) that the company will blow up and seem to take great personal risks. Of course that exists here as well in small startups but we have so strong work force-regulations that I don't think…
If anyone is considering moving into engineering management, you'd do well to look not just at the how but the why . If it's for status/salary rather than the change in nature of the work be very careful about making the move. You need to really want to manage and develop people (with all the idiosyncracies that real human beings come with!), and to communicate, co-ordinate, and delegate for a living. Some will love…
The most common reason somebody becomes an EM that I've observed is because somebody else tells them to do it. It's a promotion, so you should want it. I'm one of very few people in the SwE world I've encountered who very actively and clearly wants to do it, and for the reasons you listed - to spend more time on humans and less on code.
Most of my managers have at best tolerated the position; several have confessed being miserable and just wanting to code again ("okay, let's switch" hasn't worked, though). That includes my current and previous manager; the one before those 2 said he didn't want to manage and despite being CTO was trying to maneuver into more of an architect position, the one before that quit within a month of being promoted. I've known several people who were EMs and switched back, and had a friend confess that she was on the verge of quitting before she got offered the chance to be an IC again.
Not a one who got promoted and then loved it.
Given that it's true most ICs want to code and not manage (even if many can learn to be good managers), and these days big company ICs are very well compensated... it really feels like the driving force is external - somebody else tells them to do it, it looks like the natural progression, and that's "just what you do" more than anything else.