Show HN: I wrote a book for engineers that want to become engineering managers
244 comments
IMO being a good engineering manager is quite subjective and varies across companies and even teams. The traits of a good engineer would roughly be the same across companies and would be ranked according to knowledge, work experience and quality of code etc. And since a software engineer reports to an engineering manager, expectations are also based on the views of one person.
Upper management in different companies would have different expectations from what an engineering manager should be. Some would want them to code, some wouldn't. Some would want them to utilize developers as much as possible while some would want them to keep work life balance of developers in mind. Same with teams. A much younger team would have vastly different views on what a good manager is compared to a team which is filled up of more senior people. A younger team might want the EM to be more hands-on while a senior team would want more autonomy. Then you also have HR and feedback from various teams to deal with. Company culture and popular managers would also drive some of the traits of an engineering manager.
Having been an EM for multiple teams I've had to change my management style multiple times to better suit change in higher management and different teams. But I've always been appaled by how less content exists for learning about engineering management. Nice to see someone focus on this area!
Upper management in different companies would have different expectations from what an engineering manager should be. Some would want them to code, some wouldn't. Some would want them to utilize developers as much as possible while some would want them to keep work life balance of developers in mind. Same with teams. A much younger team would have vastly different views on what a good manager is compared to a team which is filled up of more senior people. A younger team might want the EM to be more hands-on while a senior team would want more autonomy. Then you also have HR and feedback from various teams to deal with. Company culture and popular managers would also drive some of the traits of an engineering manager.
Having been an EM for multiple teams I've had to change my management style multiple times to better suit change in higher management and different teams. But I've always been appaled by how less content exists for learning about engineering management. Nice to see someone focus on this area!
I agree this is true of engineering managers but its also true of engineers.
Some organizations want them to engage with end users and do a lot of business analysis others want them to focus on coding.
Some organizations want engineers to follow protocol and coding guidelines to the tee. Other want you to make the right call for the circumstances.
Some organizations don't care how long something takes but want it to work perfectly. Others want to make sure you deliver a product on time even if it's buggy.
Some organizations expect you to always choose the right language/tool for the job, some want you to choose the organizational language/tool everyone is familiar with.
I'm a consultant and sometimes run into this issue. Building out an MVP for a start up is a completely different mindset than working on a fortune 500 Enterprise app.
Some organizations want them to engage with end users and do a lot of business analysis others want them to focus on coding.
Some organizations want engineers to follow protocol and coding guidelines to the tee. Other want you to make the right call for the circumstances.
Some organizations don't care how long something takes but want it to work perfectly. Others want to make sure you deliver a product on time even if it's buggy.
Some organizations expect you to always choose the right language/tool for the job, some want you to choose the organizational language/tool everyone is familiar with.
I'm a consultant and sometimes run into this issue. Building out an MVP for a start up is a completely different mindset than working on a fortune 500 Enterprise app.
Same for product managers as well, ranging from technical customer support agents at enterprise fortune 500s to app developers at small startups.
In my experience, what you do as an engineering manager is quite subjective, but the principles of good management are universal. Creating a mission, focusing on results, continuous improvement, growing team members...these are all things every group needs in a manager. What you do day-to-day will change wildly from job to job and also how your own skillset evolves to meet the team's needs, but it's always in the service of these goals.
"IMO being a good engineering manager is quite subjective"
I studied Civil Engineering many years ago and was a grad. member of ICE. I'm not an Engineer or an engineer of any sort these days.
Nowadays I'm just the MD of my company.
I studied Civil Engineering many years ago and was a grad. member of ICE. I'm not an Engineer or an engineer of any sort these days.
Nowadays I'm just the MD of my company.
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 the “How to Measure Your Output as a Manager” is a bit hand waved by using Andy Grove's equation. This is a topic I struggle with because I sometimes feel that I don't produce anything as a manager and that is frustrating.
Nonetheless, the chapters I've read are fine as a starting point and appreciate that you suggest additional literature to deepen the topics.
Overall I'm positive about the book, would buy again :)
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 the “How to Measure Your Output as a Manager” is a bit hand waved by using Andy Grove's equation. This is a topic I struggle with because I sometimes feel that I don't produce anything as a manager and that is frustrating.
Nonetheless, the chapters I've read are fine as a starting point and appreciate that you suggest additional literature to deepen the topics.
Overall I'm positive about the book, would buy again :)
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?
Hi, sure, check my profile for my email.
Thank you for reviewing the book, your comment was very helpful to me :)
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 this, others hate it. But don't view it as a natural progression that will work for everyone.
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 this, others hate it. But don't view it as a natural progression that will work for everyone.
Yes, junior people frequently make the incorrect assumption that entering management is a promotion (partly because we have made the mistake of unthinkingly treating/rewarding it as such). They are often incentivized to seek management roles as part of a "this must be my career path" because of the associated salary.
It is a different role, and not merely a coder who tells people what to do. It has a different skill set, and some people will fail at / only muddle through it just like learning a new language or tool.
If you don't like dealing with people's problems, enjoy solving the problem at a detailed level and being quiet and working things out on your own, then management may not be for you.
There are companies that reward talented individual contributors as much as good managers, but they are rare. Also I would say that an individual contributor needs to be quite good to match a mediocre manager's salary, unfortunately -- but that's how the hierarchy is generally set up.
It is a different role, and not merely a coder who tells people what to do. It has a different skill set, and some people will fail at / only muddle through it just like learning a new language or tool.
If you don't like dealing with people's problems, enjoy solving the problem at a detailed level and being quiet and working things out on your own, then management may not be for you.
There are companies that reward talented individual contributors as much as good managers, but they are rare. Also I would say that an individual contributor needs to be quite good to match a mediocre manager's salary, unfortunately -- but that's how the hierarchy is generally set up.
Realistically speaking though, manager is an upwards trajectory in the CS world. Most companies don't define the IC track well, and a staff engineer is usually a 10 year veteran whereas a manager path, even if you hate it with a passion is a quick way to get a really high salary with low years of experience. Even more salary once you become director and that's not out of the realm of normal with 5-7 years of exp. I know 1 staff engineer, and 0 principal engineers, whereas I know tons of directors/VPs. Clearly, the way to more money in the long run is the manager path even if you find it horrible.
I don’t know whether you’re right or wrong, but calling someone a veteran based on 10 years of exp, and a director after 5 to 7 years sounds like a recipe for disaster. (Unless you literally started the company or something Like that).
Could this actually explain why a lot of people don’t like their managers? Because they are just too damn inexperienced.
Re: knowing few staff or principal engs, my personal anecdotal observation (and other people have told me the same), is that many engineers don’t change their titles on LinkedIn, or say they are “staff eng” etc in public. In fact, for some people, the higher they go the more they downplay their title in public. Don’t have data to back this up, just anecdotal convos with some people I know.
I’d also like to think the culture is slowly changing, about feeling forced to get into people management to progress your career. But that could be wishful thinking!
Could this actually explain why a lot of people don’t like their managers? Because they are just too damn inexperienced.
Re: knowing few staff or principal engs, my personal anecdotal observation (and other people have told me the same), is that many engineers don’t change their titles on LinkedIn, or say they are “staff eng” etc in public. In fact, for some people, the higher they go the more they downplay their title in public. Don’t have data to back this up, just anecdotal convos with some people I know.
I’d also like to think the culture is slowly changing, about feeling forced to get into people management to progress your career. But that could be wishful thinking!
> Could this actually explain why a lot of people don’t like their managers? Because they are just too damn inexperienced.
that's exactly why! i've worked and had managers who were so green and bad at their job. the staff engineers that i worked with were older folk that really have been around the block and had better communication skills than the managers. it's all extremely backwards
that's exactly why! i've worked and had managers who were so green and bad at their job. the staff engineers that i worked with were older folk that really have been around the block and had better communication skills than the managers. it's all extremely backwards
I agree with the overall point you're making.
> Clearly, the way to more money in the long run is the manager path even if you find it horrible.
Gotta break this down. How much more money would one need to make justify having a shitty time 40+ hours a week?
> Clearly, the way to more money in the long run is the manager path even if you find it horrible.
Gotta break this down. How much more money would one need to make justify having a shitty time 40+ hours a week?
Everyone's got their own numbers, I'm sure. But if you don't want to be sitting and coding at the age of 50 with 20 year olds around you "changing the world" for yet another VC startup that will fold in 4 years, your best bet is to make as much money as you possibly can as fast as you can and with some smart decisions attempt to retire in your 40s aka the FIRE thing that is popular these days. Misery is subjective but it's the smart thing to do if you want the highest probability of doing whatever you want to do later
To quote a discussion on HR from a while back (can't find the actual link in my history) - "My manager can fire me but I can't fire my manager". Manager is a promotion if only based on power dynamics.
It really does depend on the organization IMO. In a healthy organization, the managers manager can easily distinguish between contributions and fuck ups of the manager versus the same for the managers reportees.
If a team hits their metrics a good (super-) manager knows if it’s because of the manager or in spite of them, and vice versa.
What we really need is to train people to be better at identifying these organizational concerns, and set the right incentives, so that people choose to be Engineering Managers for the right reasons.
Edit: and to answer your question directly, in a healthy org, it’s definitely possible (and in fact in some very rare cases easier) to fire your manager than for them to fire you. Also depends on the level of trust you have built for yourself as in individual contributor.
If a team hits their metrics a good (super-) manager knows if it’s because of the manager or in spite of them, and vice versa.
What we really need is to train people to be better at identifying these organizational concerns, and set the right incentives, so that people choose to be Engineering Managers for the right reasons.
Edit: and to answer your question directly, in a healthy org, it’s definitely possible (and in fact in some very rare cases easier) to fire your manager than for them to fire you. Also depends on the level of trust you have built for yourself as in individual contributor.
Not to quibble, but it's a lot easier for most of us to "fire" our managers than it is for them to fire us. If your manager sucks, start interviewing.
I don't think that's a quibble. I think that's pretty fundamental. Most people don't quit their jobs, they quit their managers. And to your point, it is MUCH easier to quit than it is to fire someone. Firing someone is generally a painstaking process.
I've never had to fire someone but I've seen interviewing being very difficult. (With it being routinely common for engineers to spend months prepping on interview practice over weekends and nights before even doing their first real interview) Is firing someone really that difficult? I've seen it done on what seems like a whim - no long review process or anything.
At any mature employer if you fire someone (and it’s not due to general layoffs) you need a 6 month PIP pre-termination as legal cover.
> MUCH easier to quit than it is to fire someone
What's hard about firing people? I actually don't know and would love to find out if you could share your thought
What's hard about firing people? I actually don't know and would love to find out if you could share your thought
[deleted]
Generally (especially as companies grow) it's all about liability protection. Companies don't want to get sued, and they don't want to lose if they do get sued. That means paper trails, and attempts at showing a history of objective criteria leading to the decision, etc. This often looks like performance improvement plans and so forth, and so it can be pretty easy for someone to do just enough to not get fired but still be a quite low performer (especially with inexperienced managers).
This is flipped on its head for things like abuse where the company could be liable for not responding to reports in a timely manner. Cross a line behavior-wise, and you can get fired quickly.
This is flipped on its head for things like abuse where the company could be liable for not responding to reports in a timely manner. Cross a line behavior-wise, and you can get fired quickly.
Large organizations (and many small ones) just don't do it if there's any way to avoid it. They're rich targets for lawsuits, of course, but more importantly, it has widespread effects on morale. Fire one guy, and ten start thinking that their jobs are nowhere near as reliable as they had thought.
Managing people work is not that bad by itself - you delegate things you don't want to yourself do or you want to give more resources to.
If you can do interesting work and use your team to help, it's great. The problem with management IMO is all the politics, "managing expectations" (I think this term must have been coined by some hardcore sociopath) and team quality.
You rarely have team of senior experts only so you can focus on doing great job. You have people underperforming, having issues with others etc. Also, employee personal agenda is often more or less different from company goals - it's a constant battle.
If you can do interesting work and use your team to help, it's great. The problem with management IMO is all the politics, "managing expectations" (I think this term must have been coined by some hardcore sociopath) and team quality.
You rarely have team of senior experts only so you can focus on doing great job. You have people underperforming, having issues with others etc. Also, employee personal agenda is often more or less different from company goals - it's a constant battle.
Who cares that much about the salary when you are that point in the Software Engineeering career track in SV anyway? What, really, is the difference between making $300K/yr and even fully doubling that to $600K? A nicer apartment, a nicer car, an earlier retirement? These are pretty marginal things if the cost is spending most of your time doing something you don't like.
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.
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.
Interesting insight. I would say that most of us s/ware engineers don't live in SV though, and often a salary bump truly is a tempting and significant incentive. But I'd like to think ICs are being better accommodated now (I know we are, in some more progressive places).
> Who cares that much about the salary when you are that point in the Software Engineeering career track in SV anyway? What, really, is the difference between making $300K/yr and even fully doubling that to $600K? A nicer apartment, a nicer car, an earlier retirement? These are pretty marginal things if the cost is spending most of your time doing something you don't like.
That is the difference between being a renter in SV for the rest of your life versus being an owner. It'd also set you up for retirement and potentially let you be a single income household.
That is the difference between being a renter in SV for the rest of your life versus being an owner. It'd also set you up for retirement and potentially let you be a single income household.
Very spot on observation. I'm currently on the 'I tolerate it' bucket but I'm actively trying to hire for my replacement so I can move back to being an IC again.
At first I really disliked it but the more time I spend doing it, the better I get at it, the more rewarding it becomes. I fear by the time I find someone to actually replace me, I won't want to go back to being an IC.
At first I really disliked it but the more time I spend doing it, the better I get at it, the more rewarding it becomes. I fear by the time I find someone to actually replace me, I won't want to go back to being an IC.
It's an entirely different job, that's why nobody can just drop into it from being an engineer and magically be good at it.
Very few of the skills overlap even within the same categories such as architecture and execution. One is about the code, the other one is about the people.
Once the core skills are developed e.g. being able to clearly communicate a vision and plan, ability to have tough conversations, building interpersonal trust, being an effective salesperson for the team. Once these skills are adequately developed, it becomes a good job again.
Most people have spent at least a few years training to become a professional software engineer before being able to do that job, and yet most engineers don't give themselves/others the same understanding for developing the necessary skills to become a professional engineering manager.
Very few of the skills overlap even within the same categories such as architecture and execution. One is about the code, the other one is about the people.
Once the core skills are developed e.g. being able to clearly communicate a vision and plan, ability to have tough conversations, building interpersonal trust, being an effective salesperson for the team. Once these skills are adequately developed, it becomes a good job again.
Most people have spent at least a few years training to become a professional software engineer before being able to do that job, and yet most engineers don't give themselves/others the same understanding for developing the necessary skills to become a professional engineering manager.
I believe the best reason for this is you have looked around and soul searched and believe you are best equipped to put that team in the best position to succeed. Unfortunately, some percentage of people who come to that conclusion are sociopaths. So also don't be a sociopath..
Indeed, especially at a small company where it makes a big difference to have a capable person in charge. Even if it's not as fun as being on the front lines, it can be the responsible/right thing to do if you're the most qualified to do it.
Communicate, co-ordinate, and delegate feels like a great sound bite for what entry level management is.
What is you are sick of the churn in the coding side of work and feel you have a decent understanding of developing software?
Don't get me wrong, I'm not saying "management is a bad choice, period". Just try to be fairly sure of your own fit for it. Lots of people thrive in management it's very much "their thing"
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!
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!
Does the book cover how to get the position in the first place? I've read countless books (Like "The Managers Path" and "Managing Humans"), blog articles, etc, and tried many strategies, but it never seems to happen. Usually for the catch-22 reason of not having managing experience.
I've even had past managers they had no worries about me having the skills or knowledge to do it... but it still doesn't happen.
I've even had past managers they had no worries about me having the skills or knowledge to do it... but it still doesn't happen.
The tactic that worked for me was to bring it up to my boss. I set up a 1:1 with him, and said "In 2-3 years, I want your job. How can I get there?" (and "want your job" obviously means "to do what you do" not literally take their job)
If you have a good manager, they'll set you up for success, working with you to create a roadmap to get from IC to Manager. The steps in between would probably entail taking on larger projects, mentoring others, leading a project with multiple developers on it, and then after demonstrating all of that, you get the promotion.
In my experience, you get the promotion when you're already doing the job. In other words, you do the work and the promotion is recognition of the work you're already doing.
The other thing I'd say is that you don't get what you don't ask for. If you want to be a manager, ask for it. If you want more responsibility, ask for it. If you want better compensation or a new title, ask for it.
Unless you have a FANTASTIC manager, you will never just magically be recognized for your work. They will assume you're happy doing what you're doing and focus on greasing the squeaky wheel. To further your career, you should be a little squeaky. Ask for what you want. If you can't get it now, ask for help getting to that point.
I, as a manager, really appreciate it when someone gives me direction on what they want. Otherwise, I have to guess or try to pull it out of them, and I feel like I'm pulling teeth. It's hugely beneficial for a manager to have proactive direct reports. Be that person.
Good luck.
If you have a good manager, they'll set you up for success, working with you to create a roadmap to get from IC to Manager. The steps in between would probably entail taking on larger projects, mentoring others, leading a project with multiple developers on it, and then after demonstrating all of that, you get the promotion.
In my experience, you get the promotion when you're already doing the job. In other words, you do the work and the promotion is recognition of the work you're already doing.
The other thing I'd say is that you don't get what you don't ask for. If you want to be a manager, ask for it. If you want more responsibility, ask for it. If you want better compensation or a new title, ask for it.
Unless you have a FANTASTIC manager, you will never just magically be recognized for your work. They will assume you're happy doing what you're doing and focus on greasing the squeaky wheel. To further your career, you should be a little squeaky. Ask for what you want. If you can't get it now, ask for help getting to that point.
I, as a manager, really appreciate it when someone gives me direction on what they want. Otherwise, I have to guess or try to pull it out of them, and I feel like I'm pulling teeth. It's hugely beneficial for a manager to have proactive direct reports. Be that person.
Good luck.
Just wanted to second this. As a manager, even for people I know fairly well, I'm routinely surprised by little bits I learn as to what they want, what they dislike, or what gets them upset. Do not assume your manager can read your mind or that things are self evident and universal. With people, most things arent. Not much different than any relationship.
Just wanted to second your comment. I’m continually surprised at the number of individual contributors who (1) expect their manager to be perfect even though (s)he’s a human; (2) expect immediate gratification of their needs; (3) are only too happy to push all decision-making to the manager; (4) don’t realize that the mgr can be having a bad day; (5) compare their mgr to a friend’s mgr without comparing the job conditions; etc (not that a manager shouldn’t strive towards perfection).
OTOH, I’m also surprised by the number of managers who (1) implement something because “my friend at <massively successful co> uses <tool/process etc>; (2) don’t understand that their colleagues have lives outside work; (3) don’t realize that they’re being partial to some folks; (4) take advantage of the “meek” contributors; (5) don’t protect their team from upper mgmt when needed; (6) don’t do the grunt work when needed (and it’s always needed) etc.
In other words, just like any relationship, as you say.
OTOH, I’m also surprised by the number of managers who (1) implement something because “my friend at <massively successful co> uses <tool/process etc>; (2) don’t understand that their colleagues have lives outside work; (3) don’t realize that they’re being partial to some folks; (4) take advantage of the “meek” contributors; (5) don’t protect their team from upper mgmt when needed; (6) don’t do the grunt work when needed (and it’s always needed) etc.
In other words, just like any relationship, as you say.
This only works in growing industries. In many industries the answer has been lets see if there is a department in 3 years.
My employer has an "apprentice manager" position specifically for engineer ICs who want to transition into management. It's a 3-6 month program where you get training and coaching, and you have a dotted-line reporting relationship where you have some unofficial direct reports to practice on, and at the end of it, you can decide to either move into the management role or go back to your IC role if you decide you don't like it.
I don't know how common this kind of program is, but I went through it and found it really effective. I was able to build the skill set I needed while having an "out" if it turned out I didn't like management; the company gained an effective manager after training me; and my direct reports didn't have to suffer too much during my incompetent phase because they still had a "real" manager supporting them while I was transitioning.
If you can get an IC position at a company with a program like this (or at least a strong track-record of promoting managers from within), you might have more opportunities to move into management. But no matter what, it won't just "happen" -- you'll need your direct manager's support to get the opportunities as they arise, so you'll need to have an ongoing "here's where I want to go, let's make a plan to get me there" conversation with your manager.
I don't know how common this kind of program is, but I went through it and found it really effective. I was able to build the skill set I needed while having an "out" if it turned out I didn't like management; the company gained an effective manager after training me; and my direct reports didn't have to suffer too much during my incompetent phase because they still had a "real" manager supporting them while I was transitioning.
If you can get an IC position at a company with a program like this (or at least a strong track-record of promoting managers from within), you might have more opportunities to move into management. But no matter what, it won't just "happen" -- you'll need your direct manager's support to get the opportunities as they arise, so you'll need to have an ongoing "here's where I want to go, let's make a plan to get me there" conversation with your manager.
Start to take ownership of the things you work on. It's easier at a smaller company (like there are no engineering managers small) because that allows you to fill the role when the team grows. Besides that, expressing interest to your manager that it's something you want to do is the next thing. Trying to get hired as an engineering manager without the experience is going to be impossible unless the company is desperate for some sort of leadership so it's really only going to happen by growing into the role.
If your team is not growing then you'll never get the opportunity to become an engineering manager unless your manager quits and you fill the role. That's something to keep in mind if you've been working on a team that hasn't lost or added anyone in a while.
If your team is not growing then you'll never get the opportunity to become an engineering manager unless your manager quits and you fill the role. That's something to keep in mind if you've been working on a team that hasn't lost or added anyone in a while.
It really sucks to spend a year or two on a team that is theoretically growing only to find out that either 1) It's not actually growing and the position will never exist or 2) Somebody else on the team is the boss's favorite and has been there longer than you, so when if it does get created, they will get the role. If it's you as the new hire vs. somebody who has been there 3+ years, you are really fighting upstream.
Incidentally this strategy is why I worked at startups before this job. One did land me a lead position with 1 report, but it was when the company was falling apart and thus not the most meaningful experience. Another took the role I'd been doing by myself, and replaced it with a team and a newly minted manager... who wasn't me. I got shuffled under someone else who didn't want to manage and promptly quit, so that didn't work out either.
My company theoretically prefers senior ICs internally sourced for EM roles - it's the only place I've been able to interview for EM positions, and I very nearly got one - the hiring manager said he was set to pick me, but then they decided they really wanted somebody with deep experience at the last second.
Actually, interviewing for an internal transfer at a big company has been the closest I've come. I've also found that the big company is a lot more inclusive; startups tend to be cliquish and if you're not part of the boss's in group you will really struggle. Here, I can get involved with many things and many teams directly, so even if my boss doesn't have a job for me, I can work the network and find my place.
At least... that's the strategy I'm trying now. "We're a growing team and that position will totally be there for you a year or two down the road" applied to 4 jobs over almost 10 years without yielding any fruit. (and 2 of those companies imploded, so I didn't even get RSUs like I get now)
Incidentally this strategy is why I worked at startups before this job. One did land me a lead position with 1 report, but it was when the company was falling apart and thus not the most meaningful experience. Another took the role I'd been doing by myself, and replaced it with a team and a newly minted manager... who wasn't me. I got shuffled under someone else who didn't want to manage and promptly quit, so that didn't work out either.
My company theoretically prefers senior ICs internally sourced for EM roles - it's the only place I've been able to interview for EM positions, and I very nearly got one - the hiring manager said he was set to pick me, but then they decided they really wanted somebody with deep experience at the last second.
Actually, interviewing for an internal transfer at a big company has been the closest I've come. I've also found that the big company is a lot more inclusive; startups tend to be cliquish and if you're not part of the boss's in group you will really struggle. Here, I can get involved with many things and many teams directly, so even if my boss doesn't have a job for me, I can work the network and find my place.
At least... that's the strategy I'm trying now. "We're a growing team and that position will totally be there for you a year or two down the road" applied to 4 jobs over almost 10 years without yielding any fruit. (and 2 of those companies imploded, so I didn't even get RSUs like I get now)
The first thing is to step up and become the lead developer on your team. If you’re not being proactive folks won’t imagine it on their own. Clothes are another angle. If you look and act like a leader, soon you shall be one.
Well I am a woman, so there is that image problem automatically.
You're right about the other bit, though. Even as the most knowledgeable and senior person on the team, I do have something of a habit of letting people who are loud derail me from my ideas (or simply talk over me), which can damage perceptions. It's a thing I try to fight every day, though.
You're right about the other bit, though. Even as the most knowledgeable and senior person on the team, I do have something of a habit of letting people who are loud derail me from my ideas (or simply talk over me), which can damage perceptions. It's a thing I try to fight every day, though.
I'm curious as to what region you work in. I ask because in Silicon Valley I've seen a ton of female EMs.
In fact, my first three jobs all involved reporting to women for a good chuck of it (and they all reported to women too). Those women were all fantastic managers too. Great mentors and great empathy.
Now that I think about it, they were all promoted to management via internal promotions given to them by female managers.
So maybe one tip for you is look for an IC role that reports to a woman who is interested in mentoring you into management?
In fact, my first three jobs all involved reporting to women for a good chuck of it (and they all reported to women too). Those women were all fantastic managers too. Great mentors and great empathy.
Now that I think about it, they were all promoted to management via internal promotions given to them by female managers.
So maybe one tip for you is look for an IC role that reports to a woman who is interested in mentoring you into management?
I live and work in SF.
I don't know what magical place you work at; at the smaller (<250 people) places I've worked at, I'm the most senior woman as a Senior Software Engineer.
There are Female EMs at my current employer (enough that I can't just count them), but they are a tiny minority and I don't know of any at the level beyond that. It is a strategy I've considered, though... especially because women just seem to understand me much better.
Also a mentor or role model would be AMAZING.
I don't know what magical place you work at; at the smaller (<250 people) places I've worked at, I'm the most senior woman as a Senior Software Engineer.
There are Female EMs at my current employer (enough that I can't just count them), but they are a tiny minority and I don't know of any at the level beyond that. It is a strategy I've considered, though... especially because women just seem to understand me much better.
Also a mentor or role model would be AMAZING.
I’ve seen a few women directors/VPs of engineering, they do exist. And folks are quite used to woman managers.
I tend to get talked over as well, but it’s a slightly different subject. To clarify I mean that you solve problems without being asked. As they say about actions and words.
I tend to get talked over as well, but it’s a slightly different subject. To clarify I mean that you solve problems without being asked. As they say about actions and words.
I do have a tendency to be unconfident, to ask permission, be deferential, wait for somebody to tell me to do the thing, etc, when I could just do the thing. I tend to assume what I was going to do was wrong, especially if I get any pushback. In part because what I suggest has historically automatically been dismissed, my work and effort downplayed, etc... that doesn't seem to be a problem at my current org but I'm somewhat conditioned to assume that's the feedback I'll get anyway.
Incidentally I've never seen any of those things. At most of the smaller companies I've been at I've been the most senior woman simply as a senior engineer. Reporting to a woman sounds fantastical. I know it happens; I know a couple of female EMs at my current (bigger) company. I've essentially never had a woman in my reporting chain outside who is in the engineering org. (Across 7 jobs and about 15 years of career).
I tend to dress the part anyway and have had interview candidates assume I was the manager and my EM was the IC, but it hasn't been helpful outside of that. At worst, it can cause people to assume I'm non-technical, so it's a dangerous game to play.
Incidentally I've never seen any of those things. At most of the smaller companies I've been at I've been the most senior woman simply as a senior engineer. Reporting to a woman sounds fantastical. I know it happens; I know a couple of female EMs at my current (bigger) company. I've essentially never had a woman in my reporting chain outside who is in the engineering org. (Across 7 jobs and about 15 years of career).
I tend to dress the part anyway and have had interview candidates assume I was the manager and my EM was the IC, but it hasn't been helpful outside of that. At worst, it can cause people to assume I'm non-technical, so it's a dangerous game to play.
I think some people really do need role models, so if you don't see any female engineering managers, it may be harder to envision yourself in that position.
That said, you do need to unlearn a bunch of stuff. You have to (at least pretend to) be confident, do things without permission, be self-motivating, etc. It's going to be very difficult to manage people and have them take you seriously if you can't get yourself to do those things.
I've been in a Technical Leadership position for about 10 years, with the last four having an explicit Manager title. If I were looking for someone to groom as an EM, that person would at a minimum have to show a strong level of initiative. You don't need to be "bossy" but you do need to be able to assert yourself while still considering alternate points of view.
I can point out some of the things you need to be, but I can't tell you how to get there.
That said, you do need to unlearn a bunch of stuff. You have to (at least pretend to) be confident, do things without permission, be self-motivating, etc. It's going to be very difficult to manage people and have them take you seriously if you can't get yourself to do those things.
I've been in a Technical Leadership position for about 10 years, with the last four having an explicit Manager title. If I were looking for someone to groom as an EM, that person would at a minimum have to show a strong level of initiative. You don't need to be "bossy" but you do need to be able to assert yourself while still considering alternate points of view.
I can point out some of the things you need to be, but I can't tell you how to get there.
I have a couple of questions.
1. What type of product/service has your team been building?
2. What did you do when 10 non-permission-seeking engineers went off in different directions doing their own things?
1. What type of product/service has your team been building?
2. What did you do when 10 non-permission-seeking engineers went off in different directions doing their own things?
1. We build a variety of low-power wireless devices.
2. If you're managing people you should know what they're doing, and immediately correct this behavior. I'm a big fan of the phrase "stop doing that" because, yeah, it happens. By now my team knows that they have agency, but if they deviate from the plan to let me know.
2. If you're managing people you should know what they're doing, and immediately correct this behavior. I'm a big fan of the phrase "stop doing that" because, yeah, it happens. By now my team knows that they have agency, but if they deviate from the plan to let me know.
One worker acting alone, part time, is unable to tackle very large problems. At the point where the solution needs coordination, it happens.
I need to write a whole blog post about the subject of role models, but basically, yes. Even simple stuff like "how do I dress?" is hard to answer when you don't have role models. Or how do you resist people who talk over you without being seen as difficult?
You're right about unlearning behaviors, though easier said than done. I'm relatively self motivated when I'm not interfered with, but when I get negative feedback can easily get stuck in an analysis paralysis loop trying to figure out "what does my manager want me to do?" It's not a good sign when I'm spending time on the question of if I should even ask him or if that will be perceived as me not intrinsically knowing which will reflect badly on me.
And all that stressing about what my manager wants or how a given action will be perceived looks like laziness at best.
I'll admit, part of what I want out of being an EM is external validation that somebody trusts me to lead something. I've had a lot of bad experiences that really undermine my confidence and make me question myself.
An example: at my last job, I had a coworker who made it his personal mission to slow my velocity as much during code review as possible. One of the more egregious examples - he told me to consider using a regex rather than == to evaluate equality of strings. No particular reason. What resulted was an hours long argument... his main justification was that if I had just spent an hour to benchmark it we could have found out faster than the argument took.
You can imagine how when even extremely basic decisions of yours like that are routinely questioned it sucks out your confidence. The lead of that team explicitly had no interest in mediating this ongoing problem, and eventually promoted that guy to be the team lead so he didn't have to manage it. I meanwhile had to plan all my code around the times he'd be out of the office; I could get a month of work done in a week he was out, because somebody else would review my code. I got a reputation for missing estimates, but my timelines were entirely driven by code review cycles and thus at his whim and availability.
And yes, I repeatedly asked to work with literally anyone else, and it was only when I threatened to quit that anybody at the org actually made that happen.
There's a long history of stuff like that happening to me, and it means that I tend to just wait for somebody to tell me exactly how to do whatever it is, because the way I will do it will be seen as wrong. Who can forget the manager a couple jobs before who admitted to creating fake crises and yelling at us over nothing to keep us motivated?
This org is the first one that has actually respected me enough to do more, and where my manager's main complaint is that I act like I don't have any power, when I do. Everywhere else, it felt like they were really trying to make sure I didn't get any, and it's tough to unlearn.
You're right about unlearning behaviors, though easier said than done. I'm relatively self motivated when I'm not interfered with, but when I get negative feedback can easily get stuck in an analysis paralysis loop trying to figure out "what does my manager want me to do?" It's not a good sign when I'm spending time on the question of if I should even ask him or if that will be perceived as me not intrinsically knowing which will reflect badly on me.
And all that stressing about what my manager wants or how a given action will be perceived looks like laziness at best.
I'll admit, part of what I want out of being an EM is external validation that somebody trusts me to lead something. I've had a lot of bad experiences that really undermine my confidence and make me question myself.
An example: at my last job, I had a coworker who made it his personal mission to slow my velocity as much during code review as possible. One of the more egregious examples - he told me to consider using a regex rather than == to evaluate equality of strings. No particular reason. What resulted was an hours long argument... his main justification was that if I had just spent an hour to benchmark it we could have found out faster than the argument took.
You can imagine how when even extremely basic decisions of yours like that are routinely questioned it sucks out your confidence. The lead of that team explicitly had no interest in mediating this ongoing problem, and eventually promoted that guy to be the team lead so he didn't have to manage it. I meanwhile had to plan all my code around the times he'd be out of the office; I could get a month of work done in a week he was out, because somebody else would review my code. I got a reputation for missing estimates, but my timelines were entirely driven by code review cycles and thus at his whim and availability.
And yes, I repeatedly asked to work with literally anyone else, and it was only when I threatened to quit that anybody at the org actually made that happen.
There's a long history of stuff like that happening to me, and it means that I tend to just wait for somebody to tell me exactly how to do whatever it is, because the way I will do it will be seen as wrong. Who can forget the manager a couple jobs before who admitted to creating fake crises and yelling at us over nothing to keep us motivated?
This org is the first one that has actually respected me enough to do more, and where my manager's main complaint is that I act like I don't have any power, when I do. Everywhere else, it felt like they were really trying to make sure I didn't get any, and it's tough to unlearn.
[deleted]
Funnily enough, the company I'm at has struggled to hire women jr/sr ICs. Most of the women in the engineering organization are managers or higher level ICs.
Interesting. At my company, the curve of level vs gender is steep. Women are something like 5x more common proportionally at the lower levels than the higher ones.
This is apparently because of recruiting, too; we do great at recruiting from campuses, Grace Hopper, etc, and not at recruiting senior levels. Stats show women are getting promoted just as fast, we just don't get the candidates.
Do you know how you guys recruit more senior women? We'd love to know!
This is apparently because of recruiting, too; we do great at recruiting from campuses, Grace Hopper, etc, and not at recruiting senior levels. Stats show women are getting promoted just as fast, we just don't get the candidates.
Do you know how you guys recruit more senior women? We'd love to know!
What if you're not a very good engineer, like me? But would make a good people manager?
One of the best managers I've ever known described herself that way.
She may not have been a great engineer (I'll never know), but she gave us the tools we needed to do our job, shielded us from the upper management pressure and BS and got out of our way. In return, the team shipped a ton of functionality in an impossibly short timeframe that she later confessed she never thought we'd be able to achieve.
Excel at what you're good at and the rest tends to take care of itself.
She may not have been a great engineer (I'll never know), but she gave us the tools we needed to do our job, shielded us from the upper management pressure and BS and got out of our way. In return, the team shipped a ton of functionality in an impossibly short timeframe that she later confessed she never thought we'd be able to achieve.
Excel at what you're good at and the rest tends to take care of itself.
But to be a people lead, you ironically need to be good at engineering first ;).
One of my bigger challenges is that the older I get, the more I care about people and want to work on those issues... which means I gradually lose interest in code and pure technical stuff. The longer I stay stuck on the IC track, the more obvious this is going to become.
One of my bigger challenges is that the older I get, the more I care about people and want to work on those issues... which means I gradually lose interest in code and pure technical stuff. The longer I stay stuck on the IC track, the more obvious this is going to become.
Same thing, still: show it. Take on coordination/facilitation/people-facing roles in projects. Become a JIRA/bug triaging/product-person-facing master.
that can be fine, you just need to find an organization that emphasizes the people management side of things and has other avenues for technical leadership. Typically a place like that is self aware about it and quite upfront (as a tech lead will really hate that kind of role, and they need to understand where the technical leadership comes from). I have a friend who is very much primarily a people manager and loves it.
The book assumes someone is interested in it or just started. I didn't cover landing the job, but that's a really interesting point.
Personally, I got promoted from within at the beginning of my management journey. Have you been applying to external companies? I wonder if others on here have more experiences in that area that they'd like to share.
Personally, I got promoted from within at the beginning of my management journey. Have you been applying to external companies? I wonder if others on here have more experiences in that area that they'd like to share.
"Applying to external companies" as currently an IC looking for an EM role?
I have tried this on a limited level in the past, and either get no response or get told that I don't have experience (I have a few months with one direct report)
I have tried this on a limited level in the past, and either get no response or get told that I don't have experience (I have a few months with one direct report)
Looks very interesting! Can you also write one about how to go back to engineer from engineering manager? :)
You just read it backwards, right? :-)
That's a good point though, and I do mention it in the book. I talk about how when promoting people it's good to define a 30-60-90 day plan (although there are many similar frameworks) and bake in a "no bad feelings" back-out clause if they don't enjoy doing that particular job. We've had that happen at our company numerous times.
Additionally, in the later chapter on defining management and individual contributor tracks, it does talk about levelling them in a such a way that allows mobility back and forth. People shouldn't get stuck going through the one-way management door. It's perfectly fine to go back (even though it's not really "back", it's just "across").
That's a good point though, and I do mention it in the book. I talk about how when promoting people it's good to define a 30-60-90 day plan (although there are many similar frameworks) and bake in a "no bad feelings" back-out clause if they don't enjoy doing that particular job. We've had that happen at our company numerous times.
Additionally, in the later chapter on defining management and individual contributor tracks, it does talk about levelling them in a such a way that allows mobility back and forth. People shouldn't get stuck going through the one-way management door. It's perfectly fine to go back (even though it's not really "back", it's just "across").
Thanks, I'll make sure to check the book.
I just recently did this in my company and have been mulling over giving a talk about it.
You should! I think there's a lot of stigma around it. It's definitely not a step "down".
If you ever do give the talk, I'd love to see/hear it!
[deleted]
Congrats on the book. Have you ever explored alternative forms of management and organizational forms? Stuff like Sociocracy, Teal (from Reinventing Organizations) or management as envisioned by Deming. I wonder whether the engineering manager role as usually interpreted isn't really an anti-pattern, I mean we're basically applying Taylorism to knowledge work.
Thank you! I haven't gone into detail about these in the book. This is very much the standard Engineering Manager route that people would find in most places in industry right now.
However - if you don't mind - I would love to use those as examples in the final chapters where I mention the opportunities offered by moving into start-ups, and also where our managers will be given more autonomy to set the culture of a wider organization (of which that culture could involve much looser management structures).
Great pointers, thank you.
However - if you don't mind - I would love to use those as examples in the final chapters where I mention the opportunities offered by moving into start-ups, and also where our managers will be given more autonomy to set the culture of a wider organization (of which that culture could involve much looser management structures).
Great pointers, thank you.
Cool! I actually work at a company that adopted Holacracy roughly 3 years ago. In many ways it's probably much less loose and more formal than most people think (I mean there is a written constitution written in Legalese).
There are still roles that resemble the classical management role, i.e. there is a role that is responsible for setting strategies and assigning people into roles and monitoring role fit within their 'circle' (think team or business unit), called the circle's lead link. Yet there is a process for any role holder to propose putting those accountabilities into a new role or into a process. Role holders can also propose the creation of new roles or policies if they feel a tension. Then there is a structured process to deal with these proposals, and people need to demonstrate that the proposal would cause harm and reduce the capacity for the circle to achieve its purpose in order to have a valid objection. People in roles ultimately have ultimate autonomy on how they want to achieve their role's purpose. The lead link role can give relative prioritization if there are conflicts, but the lead link can't say 'you have to work on this right now and this is how you gonna do it'.
What ultimately happens is that the traditional accountabilities of a manger end up being distributed across multiple roles, so people might have software developer role, but might also be responsible for defining the hiring standards, or do people development etc.
It's kinda similar to the book "Turn the Ship around" where you don't have to ask for permission to do something and there is a process to address any tensions that arise from this power to act autonomously.
There are still roles that resemble the classical management role, i.e. there is a role that is responsible for setting strategies and assigning people into roles and monitoring role fit within their 'circle' (think team or business unit), called the circle's lead link. Yet there is a process for any role holder to propose putting those accountabilities into a new role or into a process. Role holders can also propose the creation of new roles or policies if they feel a tension. Then there is a structured process to deal with these proposals, and people need to demonstrate that the proposal would cause harm and reduce the capacity for the circle to achieve its purpose in order to have a valid objection. People in roles ultimately have ultimate autonomy on how they want to achieve their role's purpose. The lead link role can give relative prioritization if there are conflicts, but the lead link can't say 'you have to work on this right now and this is how you gonna do it'.
What ultimately happens is that the traditional accountabilities of a manger end up being distributed across multiple roles, so people might have software developer role, but might also be responsible for defining the hiring standards, or do people development etc.
It's kinda similar to the book "Turn the Ship around" where you don't have to ask for permission to do something and there is a process to address any tensions that arise from this power to act autonomously.
This is fascinating, thanks! Turn The Ship Around is on my reading list.
I transitioned from software engineer to engineering management 2 years ago. It was by far the most challenging (still rewarding) moment of my career. I was lucky to have the opportunity to build up a team from scratch to take over the services and architecture I designed, developed and operated.
Biggest lesson learned: you're no longer the decision-maker on your technical stack. Your team is responsible. Still, you’re liable for the result and its impact on business. That duality is hard to reconcile for former engineer. The solution? Build a culture. Better: create the conditions for a sustainable culture to emerge and persist.
That insight, and many other advices for new managers are compiled at: https://github.com/kdeldycke/awesome-management
Biggest lesson learned: you're no longer the decision-maker on your technical stack. Your team is responsible. Still, you’re liable for the result and its impact on business. That duality is hard to reconcile for former engineer. The solution? Build a culture. Better: create the conditions for a sustainable culture to emerge and persist.
That insight, and many other advices for new managers are compiled at: https://github.com/kdeldycke/awesome-management
I don't know whether it's in the book - perhaps it's in the "How to Win Friends and Influence People" chapter - but one thing I struggle with is communicating outwards and upwards.
I tend to assume that everybody else in the company knows that my team works in the way it does because that's how you deliver software successfully. Often, this comes back to bite when I learn that other managers think the team should be managed differently, and because I haven't made enough efforts to sell our methodology, those managers can have more influence than I'd like.
So, as an Engineering Manager, it's not enough that everybody in your team is happy and produce. You also have to be an advocate for your team to the rest of the company.
I tend to assume that everybody else in the company knows that my team works in the way it does because that's how you deliver software successfully. Often, this comes back to bite when I learn that other managers think the team should be managed differently, and because I haven't made enough efforts to sell our methodology, those managers can have more influence than I'd like.
So, as an Engineering Manager, it's not enough that everybody in your team is happy and produce. You also have to be an advocate for your team to the rest of the company.
To expand on your last point, I've found 90% of the success of your team is largely based on your team's ability to self-promote. I like to "talk up" my senior people when they're not in the room. This is the "upwards" part as a manager's influence is largely restricted to the management class. Most engineers roll their eyes and discount about 50% of what a manager outside their team says, so you likely won't be able to build credibility with them yourself no matter what you do.
The "outwards" part is teaching your team the right ways to evangelize to people on other teams at levels below you. They'll almost certainly be interacting with engineers on other teams, and the quality of these interactions is greatly enhanced with a combination of good documentation and good presentation skills.
This is so important that it doesn't really matter how good of a job your team does as long as they can talk about it in a positive way and work effectively with other teams. All of your "good engineering practices" should be geared towards enabling this kind of culture because the technical deficiencies in your code don't really matter.
The "outwards" part is teaching your team the right ways to evangelize to people on other teams at levels below you. They'll almost certainly be interacting with engineers on other teams, and the quality of these interactions is greatly enhanced with a combination of good documentation and good presentation skills.
This is so important that it doesn't really matter how good of a job your team does as long as they can talk about it in a positive way and work effectively with other teams. All of your "good engineering practices" should be geared towards enabling this kind of culture because the technical deficiencies in your code don't really matter.
> I've found 90% of the success of your team is largely based on your team's ability to self-promote.
This makes me feel bad about my past behavior. I've walked in on past managers when they've been talking about my accomplishments or background with other managers or company owners. My instinct, and the way I was raised (military family), is to play it down and be humble ("eh, it was a team effort", or "I was in the right place and right time") or make some self-deprecating joke, but now I can see I was likely (unintentionally) undermining my boss.
I had already realized this wasn't a good idea the last time it happened, and resolved next time to just smile and say thank you or something similarly neutral. However, this comment underlines how bad of an idea it is to play down your successes at work, even if it's in your nature (I've also had people openly tell me to be careful about this re: my own career).
I just can't stand people boasting about bullshit at work, and want to avoid coming across like that. But I'll be more careful about playing down my own successes now.
This makes me feel bad about my past behavior. I've walked in on past managers when they've been talking about my accomplishments or background with other managers or company owners. My instinct, and the way I was raised (military family), is to play it down and be humble ("eh, it was a team effort", or "I was in the right place and right time") or make some self-deprecating joke, but now I can see I was likely (unintentionally) undermining my boss.
I had already realized this wasn't a good idea the last time it happened, and resolved next time to just smile and say thank you or something similarly neutral. However, this comment underlines how bad of an idea it is to play down your successes at work, even if it's in your nature (I've also had people openly tell me to be careful about this re: my own career).
I just can't stand people boasting about bullshit at work, and want to avoid coming across like that. But I'll be more careful about playing down my own successes now.
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 to customers or deadline promises D) giving ourselves room to fail, because not everything will work out.
The current iteration is a fortnightly newsletter that I curate between product and the engineering managers in the department and it gets sent around, but making everyone happy with it is /so/ hard.
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 to customers or deadline promises D) giving ourselves room to fail, because not everything will work out.
The current iteration is a fortnightly newsletter that I curate between product and the engineering managers in the department and it gets sent around, but making everyone happy with it is /so/ hard.
We have an internal website with user-maintained groups/content. Every week, you get an email with major updates from the teams you want based on the important information they've been telling themselves. That's been useful for culling and focusing the information flow to each person.
In my experience, newsletters don't work well for internal communication. As you said, keeping the content relevant to a wide readership is too difficult. It does, however, work well as a recognition mechanism. A team seeing it's achievements blasted out to the company is very motivating, even if they are the only one's who notice it.
In my experience, newsletters don't work well for internal communication. As you said, keeping the content relevant to a wide readership is too difficult. It does, however, work well as a recognition mechanism. A team seeing it's achievements blasted out to the company is very motivating, even if they are the only one's who notice it.
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.
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.
Thank you!
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.
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.
Gifs? Don’t low quality animations make it hard to read?
When they're embedded in a Google Doc, they're pretty good at getting the point across - then they can have a link to the app itself too.
> Often, this comes back to bite when I learn that other managers think the team should be managed differently.
I’m going through this right now at my company, and it’s completely devastating our engineering org’s morale. I’ve never experienced anything like this.
I’m going through this right now at my company, and it’s completely devastating our engineering org’s morale. I’ve never experienced anything like this.
I've seen this handled by making a team charter. It describes who you are and what you do in a couple paragraphs (no more than a page). Put it in front of upper management for comment/approval. Share it widely and keep it on hand when meeting with upper management or other teams. Expect it to be a living doc.
Managing expectations is hard. Everyone will have different expectations of you unless you handle it for them.
Managing expectations is hard. Everyone will have different expectations of you unless you handle it for them.
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 feels like he needs to roll up his sleeves and contribute.
2.)He has some form of attention deficit, demonstrated by the fact that he can't hold down a conversation really well. Especially if it gets technical.
3.)He really overplays the busy body persona. Always checking phone, always late for a meeting.
4.)He's really insecure in his position within the company, always fearful that he's going to be cut loose. This is extremely amplified when he gets a new manager himself.
5.)He has very little influence over direction. He's really just a proxy mouthpiece for higher level management. And he loves to have status update meetings where he informs the team of all the important updates he received in the big important meeting he attended with other big important people.
6.)Instead of being someone who is respected by the team, he becomes more of someone you have sympathy for.
7.)You wonder why he never asks the real questions, like "are you happy with your role?". And you realize it's because he doesn't really want to hear the answer. He couldn't really do anything about it anyway. See point #5.
8.) He's way too preoccupied worrying about his own safety to nurture the team.
9.) As a developer, you have the safety net of knowing that in the worst case scenario (terminated) you could find another job fairly quickly with pay parody. As a manager, you don't have that comfort blanket. So you cling on to your current job no matter how badly you are abused. And people lose more respect for you because you look pathetic without a backbone.
10.) As a cynical developer in his 40's, you realize that you don't observe many 50+ developers in the wild, and you bemoan the idea that you're going to have to suck it up and play manager eventually.
Anxiety and existential crisis is built into the tech career trajectory, and I feel like the only winning strategy is to be ok with moving backward income wise at various points in your timeline.
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 feels like he needs to roll up his sleeves and contribute.
2.)He has some form of attention deficit, demonstrated by the fact that he can't hold down a conversation really well. Especially if it gets technical.
3.)He really overplays the busy body persona. Always checking phone, always late for a meeting.
4.)He's really insecure in his position within the company, always fearful that he's going to be cut loose. This is extremely amplified when he gets a new manager himself.
5.)He has very little influence over direction. He's really just a proxy mouthpiece for higher level management. And he loves to have status update meetings where he informs the team of all the important updates he received in the big important meeting he attended with other big important people.
6.)Instead of being someone who is respected by the team, he becomes more of someone you have sympathy for.
7.)You wonder why he never asks the real questions, like "are you happy with your role?". And you realize it's because he doesn't really want to hear the answer. He couldn't really do anything about it anyway. See point #5.
8.) He's way too preoccupied worrying about his own safety to nurture the team.
9.) As a developer, you have the safety net of knowing that in the worst case scenario (terminated) you could find another job fairly quickly with pay parody. As a manager, you don't have that comfort blanket. So you cling on to your current job no matter how badly you are abused. And people lose more respect for you because you look pathetic without a backbone.
10.) As a cynical developer in his 40's, you realize that you don't observe many 50+ developers in the wild, and you bemoan the idea that you're going to have to suck it up and play manager eventually.
Anxiety and existential crisis is built into the tech career trajectory, and I feel like the only winning strategy is to be ok with moving backward income wise at various points in your timeline.
Ditto (almost verbatim to what you wrote). I've been meditating on a few reasons for it:
1) I was given a few opportunities by the partners to step up into a management role, but in hindsight, I was too knee-deep in code to see what was happening, so I doubled down on keeping my nose to the grindstone rather than stepping back and thinking more about how to change the workflow so that others could come in and contribute. The symptoms of this were things like: I never got invited to any public-facing events, team building exercises or drinks with the partners when they were in town. I think they viewed me as a big fish in a small pond, someone to be utilized but not groomed. They came from a big city hustle mindset whereas I came from small town America. So different value systems, not necessarily superior or inferior, but at high risk of miscommunication.
2) When they finally promoted the other guy to a management role, he fell into the exact sequence you enumerated. He was highly disciplined and methodical, but sometimes had blind spots about different local maximums in the search space (had trouble seeing the forest for the trees) and was a bit too focused on maintaining the hierarchy since he came from a military background. I admired his tenacity, but truthfully, it had a tendency to wear on the developers (several of which had an antiauthoritarian mindset like many in tech).
3) When he moved on, a void was left that was never filled. We ended up changing over to nontechnical project managers, which worked well for about a year, but inevitably the agency drifted towards enterprise work, which is not my cup of tea. We had a bit of a falling out and I moved on. I still wonder to this day how things might have ended up differently if I had stepped up and basically listened to the universe and manifested whatever the next chapter of my life as a team lead or manager was going to be. I would have been a highly egalitarian manager, working for the team as much as for the partners and clients. Now, I dunno, I'm not sure that my heart is in software engineering anymore. I'm focusing on the gig economy and attaining some financial independence outside of hierarchy so I can finally work on projects within my own calling. As a 40-something this is scary but rejuvenating.
1) I was given a few opportunities by the partners to step up into a management role, but in hindsight, I was too knee-deep in code to see what was happening, so I doubled down on keeping my nose to the grindstone rather than stepping back and thinking more about how to change the workflow so that others could come in and contribute. The symptoms of this were things like: I never got invited to any public-facing events, team building exercises or drinks with the partners when they were in town. I think they viewed me as a big fish in a small pond, someone to be utilized but not groomed. They came from a big city hustle mindset whereas I came from small town America. So different value systems, not necessarily superior or inferior, but at high risk of miscommunication.
2) When they finally promoted the other guy to a management role, he fell into the exact sequence you enumerated. He was highly disciplined and methodical, but sometimes had blind spots about different local maximums in the search space (had trouble seeing the forest for the trees) and was a bit too focused on maintaining the hierarchy since he came from a military background. I admired his tenacity, but truthfully, it had a tendency to wear on the developers (several of which had an antiauthoritarian mindset like many in tech).
3) When he moved on, a void was left that was never filled. We ended up changing over to nontechnical project managers, which worked well for about a year, but inevitably the agency drifted towards enterprise work, which is not my cup of tea. We had a bit of a falling out and I moved on. I still wonder to this day how things might have ended up differently if I had stepped up and basically listened to the universe and manifested whatever the next chapter of my life as a team lead or manager was going to be. I would have been a highly egalitarian manager, working for the team as much as for the partners and clients. Now, I dunno, I'm not sure that my heart is in software engineering anymore. I'm focusing on the gig economy and attaining some financial independence outside of hierarchy so I can finally work on projects within my own calling. As a 40-something this is scary but rejuvenating.
I get that you were being deliberately a wee bit provocative, but If you honestly believed that of every manager you had, you would have been a horrible co-worker.
Without commenting on the specifics on your comment: what does this have to do with the OP's book? If anything, writing a book with ideas, experiences, and techniques aimed at helping people be better at this job is responsive to all the problems you identify.
It speaks to a real predicament that the OP is aiming to solve with techniques and ideas. BTW, If you are interested in techniques and ideas do us a favor and become a scientist.
Just commentary on the engineer turned manager narrative. Please forgive if it is out of place. Should I delete it?
Nah sorry for calling you out like that, it's slightly off topic but a fine rant. For what it's worth, I agree with many of your points, but hope we can do better as the profession continues to mature.
Yes, and delete Dilbert too as it makes this engineering approach to management seem more complex than we'd like it to be.
Your description resonates quite well with my own experience. I've seen this over and over again in different (mostly large) enterprises. Peter principle at its best where someone with solid engineering skills gets promoted to become mediocre manager to the detriment of the rest of the team.
I think for someone considering engineering manager track your point #9 is really something to keep in mind. Many managers I've met are well aware of the fact that they're simply unemployable outside of their current company, which essentially becomes a "prison" for them.
I think for someone considering engineering manager track your point #9 is really something to keep in mind. Many managers I've met are well aware of the fact that they're simply unemployable outside of their current company, which essentially becomes a "prison" for them.
That sounds like managers who haven't been trained.
Leadership is a skill like any other. You can't just promote someone into it. They have to be trained for it.
Leadership is a skill like any other. You can't just promote someone into it. They have to be trained for it.
This gave me a laugh
> pay parody
Definitely at a startup.
Most of us would be looking for pay _parity_ :)
> pay parody
Definitely at a startup.
Most of us would be looking for pay _parity_ :)
You need to work for better organisations with better people. Which you definitely will not be hired into without a major attitude adjustment.
[deleted]
Hey I made an app to help me be a better engineering manager, I’d love your opinion on it if you had some time.
https://apps.apple.com/us/app/team-lead/id1466421445?mt=8
https://play.google.com/store/apps/details?id=co.jmoses.manu...
https://apps.apple.com/us/app/team-lead/id1466421445?mt=8
https://play.google.com/store/apps/details?id=co.jmoses.manu...
> If anyone's at all interested in learning about what it's like to pitch a publisher with their own book idea, then I guess I've been successful at that now, so I'm more than happy to give you any advice.
Maybe this needs to be a new book?
Seriously, all of this sounds wonderful - and thank you (but I would love to hear some tips on getting a book published from zero - I certainly write enough that I could probably fill a book, whether anyone would read it though...???).
Maybe this needs to be a new book?
Seriously, all of this sounds wonderful - and thank you (but I would love to hear some tips on getting a book published from zero - I certainly write enough that I could probably fill a book, whether anyone would read it though...???).
I'd love to hear more about this as well.
This looks interesting. I assume that this is very us-centric though? Have you gotten any international reactions/feedback during writing? I guess it's har to say but how applicable would this be in other parts of the engineering world? I've only worked in tech in Sweden and I sometimes feel like that "it's pretty much the same" but other times: "us tech scene is aliens on another planet".
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 it can get that extreme. And now that I think of it it might be that we are the odd ones so maybe it's not so much u.s. vs. e.u. as u.s. vs sweden. ¯\_(ツ)_/¯
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 it can get that extreme. And now that I think of it it might be that we are the odd ones so maybe it's not so much u.s. vs. e.u. as u.s. vs sweden. ¯\_(ツ)_/¯
I understand. Yeah, we're a VC-backed company but it didn't feel like the journey was a movie script at any point.
[deleted]
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 underestimated
- 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 underestimated
1000x less fun? That’s extremely subjective, and depends enormously on what you draw satisfaction from. Leading people can be a lot of fun if you genuinely care about the people you are leading and take joy from empowering and enabling them to grow and succeed.
Yes and no. You can move mountains with good teams, this is great and you will draw satisfaction from. But IDK if you had ever 100+ people in your reporting line for a longer time. Then you knew that it's everything BUT definitely not a lot of fun. It's super hard work and will push you and your mind dangerously to the limit.
It's a different mindset, but I still think it's fun. For me, the key with that size of a group was focusing on the development of the leaders under me. When I make sure they are set up for success, things go smoothly.
The hardest time in my life was trying to micromanage a large group. Once you let go, and focus on the bigger picture, it's quite fun. Challenging, for sure, but very fun.
The hardest time in my life was trying to micromanage a large group. Once you let go, and focus on the bigger picture, it's quite fun. Challenging, for sure, but very fun.
Hint: you should never frame your reports in such a way ('leaders under me'), 101 of leadership; but let's move on: I think we are not talking about the same; managing people has no short-term feedback loops like coding, it can be fun yes but many confuse this fun with the status involved; from a rational perspective and with the experience of heading larger headcounts (did you lead 100+ teams for a longer time?) paired with hitting ambitious org goals, I find it hard to call 'managing people' fun.
Holdover from the military. I can see you're framing it as "beneath", which would be very inappropriate, but it references "under your charge". Thanks for pointing out that it could be misconstrued.
I am sorry to hear you have not enjoyed your time leading a large group. It certainly has its challenges, but I assure you it can be quite fun and rewarding.
I am sorry to hear you have not enjoyed your time leading a large group. It certainly has its challenges, but I assure you it can be quite fun and rewarding.
This is getting a bit too deep now. I didn't say that I didn't enjoy it. I like challenges, my initial notion was just to express that words like 'fun' are far away from what leadership is. Btw, you didn't answer the question if you led 100+ people for a longer time. Besides and no offense, military, authoritative leadership styles might not be the right approach in tech environments (like those where engineers work).
With regards to the military, good leadership works in any organization. I do not speak to my engineers the way I would speak to a platoon, but I lead them the same.
Quite a few years running teams up to 300, now about 3000.
[deleted]
And you have time to be on HN?
What is the proper way to frame reports? "leaders reporting to me", "managers I manage"?
DNA evidence works well.
In all seriousness, I recommend not referring to them as "reports" at all. Call them "My Team", "us", "we". It creates a sense of collective ownership.
When talking up, I use specific names, or "the team" to reference tasks or successes, and "I" when we talk about failures. I own what goes wrong, they own what goes right.
In all seriousness, I recommend not referring to them as "reports" at all. Call them "My Team", "us", "we". It creates a sense of collective ownership.
When talking up, I use specific names, or "the team" to reference tasks or successes, and "I" when we talk about failures. I own what goes wrong, they own what goes right.
Hm, how should this work? If I'd ask you, 'How many direct reports do you have', what would you say? You need to use the term 'direct report' again.
If you fuzzed around with 'my team' while I try to understand you team structure, your direct report count, their profile, which and how many reports they again have, you'd drive me nuts with a fake 'my team' humbleness.
Using the term 'report' is absolutely ok, you shouldn't talk all day long of your reports of course or trying to impressive anyone.
If you fuzzed around with 'my team' while I try to understand you team structure, your direct report count, their profile, which and how many reports they again have, you'd drive me nuts with a fake 'my team' humbleness.
Using the term 'report' is absolutely ok, you shouldn't talk all day long of your reports of course or trying to impressive anyone.
You seem to be taking something about this thread very personally. I'm sorry for that. I hope you have a good day.
You think so? I just disagreed with the things you wrote because I think some of your statements are wrong and/or mislead and they're altogether also inconsistent.
I don't believe they are inconsistent, but I also have the advantage of knowing my own life intimately. I suppose the context makes a difference.
There are very few "rules" in this game, so feel free to manage differently. You have 100+ on your team, so I'm sure your methods worked well for you, as mine have for me.
There are very few "rules" in this game, so feel free to manage differently. You have 100+ on your team, so I'm sure your methods worked well for you, as mine have for me.
Just reports. The ones directly reporting to you are called 'direct reports'. Latter also implies a bigger headcount and that the direct reports are managers themselves. So if you have a small, flat team you call your direct reports just reports.
I for one think the expression 'leaders under me' is clear, accurate and inoffensive to anyone.
Okay. And lots of people don't find grabbing tickets and coding all day to be a lot of fun.
Management is work. But so is coding. Some people prefer one. Some people prefer the other.
Management is work. But so is coding. Some people prefer one. Some people prefer the other.
100+ people doesn't scale. This is not how you lead. You need to form a pyramid structure or your leadership won't be effective.
You think I meant 100 direct reports? Without any structure?
No. But 100 in your direct line doesn't scale. These people should be invisible to you.
It would be impossible for someone to be CEO of say Google under your logic.
It would be impossible for someone to be CEO of say Google under your logic.
I don't see this as subjective, because dealing with computers and technology is a fundamentally different type of activity, and requires a totally different set of skills, than dealing with people. If you're the type of person who enjoys the former, I think it's safe to say you won't enjoy the latter much, at least not at first.
> dealing with computers and technology is a fundamentally different type of activity, and requires a totally different set of skills, than dealing with people.
Sure.
> If you're the type of person who enjoys the former, I think it's safe to say you won't enjoy the latter much
This seems like a bit of a leap. People can be good at and enjoy things that are very different.
Sure.
> If you're the type of person who enjoys the former, I think it's safe to say you won't enjoy the latter much
This seems like a bit of a leap. People can be good at and enjoy things that are very different.
Yes but the context here is coder transforms to manager. And coders got coders because they like short feedback-loops.
Nope, I became a coder because I want to be able to create apps that I have in my head. I hated coding for the first 6 months (I'm on year 8 now). Now I like it, but I'm still not passionate about it.
My passion is about digital creation.
I think I'd like being a manager, depending on the context. Since I like to talk and listen to people their ideas and get energy from talking and listening.
I don't get energy from coding. I do get energy from creating something awesome (either myself or with a team).
My passion is about digital creation.
I think I'd like being a manager, depending on the context. Since I like to talk and listen to people their ideas and get energy from talking and listening.
I don't get energy from coding. I do get energy from creating something awesome (either myself or with a team).
Nice that you told us the story why you got into coding. I just tried to find an abstraction for the sake of simplicity. Of course we had all our triggers why we got into coding. And of course we had some specific end goal like you had but the actual activity of coding is about short feedback loops. Something which many professions lack. If you didn't like short feedback-loops you wouldn't code for 8 years.
> If you're the type of person who enjoys the former, I think it's safe to say you won't enjoy the latter much, at least not at first.
I disagree, I volunteered (edit: to step up and take on) for a manager role and discovered I loved it. I really enjoy helping built teams and team culture, helping people learn and grow in their career and abilities, and working to coordinate work across multiple teams to get work done at a scale that I never could have as an IC.
Saying that people who enjoy coding don't like dealing with people is like saying people who enjoy painting won't like programming, it is a stereotype that is easily dis-proven by the existence of people who, in both cases, do enjoy both!
I disagree, I volunteered (edit: to step up and take on) for a manager role and discovered I loved it. I really enjoy helping built teams and team culture, helping people learn and grow in their career and abilities, and working to coordinate work across multiple teams to get work done at a scale that I never could have as an IC.
Saying that people who enjoy coding don't like dealing with people is like saying people who enjoy painting won't like programming, it is a stereotype that is easily dis-proven by the existence of people who, in both cases, do enjoy both!
Managing people != dealing with people
This is the biggest misconception most have you have never led seriously. I like people, I like meeting people for a beer, for pair-programming, to date. Managing people is not about being with people.
This is the biggest misconception most have you have never led seriously. I like people, I like meeting people for a beer, for pair-programming, to date. Managing people is not about being with people.
> This is the biggest misconception most have you have never led seriously.
As a manager, I managed my team, and dealt with a lot of other teams!
I was spending a good % of my time coordinating, organizing, and paving the way for my team to do good work. Ranging from ensuring the UI specs that got to them had been well vetted, to negotiating release schedules with other teams.
This extends even to engineering decisions. As an example, there were ways my team could implement a feature that'd save us time, but be harder for an upstream team to integrate with, or we could take more time implementing something to their requests at a cost to our schedule.
Balancing decisions like that is just as much talking to people in hallways between meetings as it is attending those meetings. It is forming relationships across an organization so that even when schedules get tight and times are tense, things don't get ugly.
As a manager, I managed my team, and dealt with a lot of other teams!
I was spending a good % of my time coordinating, organizing, and paving the way for my team to do good work. Ranging from ensuring the UI specs that got to them had been well vetted, to negotiating release schedules with other teams.
This extends even to engineering decisions. As an example, there were ways my team could implement a feature that'd save us time, but be harder for an upstream team to integrate with, or we could take more time implementing something to their requests at a cost to our schedule.
Balancing decisions like that is just as much talking to people in hallways between meetings as it is attending those meetings. It is forming relationships across an organization so that even when schedules get tight and times are tense, things don't get ugly.
Tbh, this sounds you like are heavily micromanaging your people because you don't have any task yourself. Did you ever got into 360 feedback? How was the outcome?
I wasn't micro-managing my people, I was managing interactions with other teams.
For reference, we had software running on the cloud, mobile, and devices, with multiple teams at each tier.
API changes were a mess of coordination. It wasn't "send JSON" it was "round trip this in a way that can be consumed by a device with 256KB of RAM." Multiple transforms of data across multiple mobile platforms meant just locking down on field orders could be problematic if someone didn't take proper notes[1], or if a Java programmer on Android didn't understand how to properly consume an unsigned 8bit int.
Early on in the project, we had a design team that hadn't yet been trained on what 96mhz CPU could do in terms of UI. I was doing careful reviews of UI designs, and eventually was just sitting in design meetings, to ensure that by the time specs got to my team the spec was physically doable.
Another example, when it comes to performance. I was going over EE schematics to ensure there was sufficient bandwidth to push pixels how the UX team wanted. Part of my job was working as a go-between for EE and UX and explaining the other teams POV to people with very different backgrounds.
Then there is the more soft-skill stuff. Seeing months ahead of time that another team would be having problems in the future, and suggesting to one of my senior engineers that making some friends over there and getting up to speed on their code base ahead of time might be useful, so that in a few months when help is asked for he can jump in and assist.
Letting senior management down gently that their favorite feature is going to be cut.
Prioritizing what features we need to implement to show "progress" to upper management so that we can all stay employed. This often required guessing far ahead of time what we'd eventually be told to demo "next week", and having work start on it way ahead of time. These were very much "do or die" demos.
The feature work? The team sat in a pod and discussed technical implementations with each other. I trusted the people I had hired to do good work, that is why I had hired them. I had the huge benefit of having personally hired every member on the team, which is one of the things that made any of the above possible.
Then there is the actual team management stuff. Inviting engineers to the right meeting so that they had visibility, giving them a chance to speak up in front of senior leadership so that their name was known. Taking someone who I saw leadership potential in and helping them see it, and giving them opportunities to grow that potential.
Rotating user facing features around between engineers so that they all had something they could point to and say "I made that shiny thing!" Good for both morale and career visibility.
Preventing burn-out. Telling PMs that work was going to be delayed because the engineer best suited to doing it was going to be working 6 hour days on light duty because they just went through a 2 month crunch.
Ensuring senior leadership heard the name of the engineer(s) responsible when something went right, and only heard my name if something went wrong.
Managing is a lot of work, but I think your judgements about it are unfair. Managing engineering projects is a blend of technical and people skills, and there is no law of the universe that says someone can't enjoy both.
[1] Or ignored the spec sent out. Or wasn't aware there was a spec. Or we were told we had to have this working in a matter of days so there was no spec. Or there was a bug in the deserializer that ended up swapping two fields. That last one took awhile to figure out.
For reference, we had software running on the cloud, mobile, and devices, with multiple teams at each tier.
API changes were a mess of coordination. It wasn't "send JSON" it was "round trip this in a way that can be consumed by a device with 256KB of RAM." Multiple transforms of data across multiple mobile platforms meant just locking down on field orders could be problematic if someone didn't take proper notes[1], or if a Java programmer on Android didn't understand how to properly consume an unsigned 8bit int.
Early on in the project, we had a design team that hadn't yet been trained on what 96mhz CPU could do in terms of UI. I was doing careful reviews of UI designs, and eventually was just sitting in design meetings, to ensure that by the time specs got to my team the spec was physically doable.
Another example, when it comes to performance. I was going over EE schematics to ensure there was sufficient bandwidth to push pixels how the UX team wanted. Part of my job was working as a go-between for EE and UX and explaining the other teams POV to people with very different backgrounds.
Then there is the more soft-skill stuff. Seeing months ahead of time that another team would be having problems in the future, and suggesting to one of my senior engineers that making some friends over there and getting up to speed on their code base ahead of time might be useful, so that in a few months when help is asked for he can jump in and assist.
Letting senior management down gently that their favorite feature is going to be cut.
Prioritizing what features we need to implement to show "progress" to upper management so that we can all stay employed. This often required guessing far ahead of time what we'd eventually be told to demo "next week", and having work start on it way ahead of time. These were very much "do or die" demos.
The feature work? The team sat in a pod and discussed technical implementations with each other. I trusted the people I had hired to do good work, that is why I had hired them. I had the huge benefit of having personally hired every member on the team, which is one of the things that made any of the above possible.
Then there is the actual team management stuff. Inviting engineers to the right meeting so that they had visibility, giving them a chance to speak up in front of senior leadership so that their name was known. Taking someone who I saw leadership potential in and helping them see it, and giving them opportunities to grow that potential.
Rotating user facing features around between engineers so that they all had something they could point to and say "I made that shiny thing!" Good for both morale and career visibility.
Preventing burn-out. Telling PMs that work was going to be delayed because the engineer best suited to doing it was going to be working 6 hour days on light duty because they just went through a 2 month crunch.
Ensuring senior leadership heard the name of the engineer(s) responsible when something went right, and only heard my name if something went wrong.
Managing is a lot of work, but I think your judgements about it are unfair. Managing engineering projects is a blend of technical and people skills, and there is no law of the universe that says someone can't enjoy both.
[1] Or ignored the spec sent out. Or wasn't aware there was a spec. Or we were told we had to have this working in a matter of days so there was no spec. Or there was a bug in the deserializer that ended up swapping two fields. That last one took awhile to figure out.
On the other hand, an effective leader can
- usually tackle bigger problems/projects than they could ever address as an IC
- make sure their team isn't wasting time on the wrong things
- accelerate the development of inexperienced team members
- make sure that the team is more than the sum of it's parts; hopefully very much more
- avoid getting bogged down on technical details that will not be relevant for long. Some of the skills you had that will atrophy aren't very impactful, just necessary at the moment.
Some people will find those things rewarding, and may not find your 1000x factor at all realistic.
- usually tackle bigger problems/projects than they could ever address as an IC
- make sure their team isn't wasting time on the wrong things
- accelerate the development of inexperienced team members
- make sure that the team is more than the sum of it's parts; hopefully very much more
- avoid getting bogged down on technical details that will not be relevant for long. Some of the skills you had that will atrophy aren't very impactful, just necessary at the moment.
Some people will find those things rewarding, and may not find your 1000x factor at all realistic.
Sorry, but what you write could come from any of the millions of self-help leadership books or blog spam from the net. Random, generic advice. This is too simple for my taste and I am not talking about what effective leadership is. Maybe you talk about a first leadership experience or managing two interns and find this rewarding. Yes this is def fun.
I was replying to something generic, balancing out the negatives a bit. I wasn't really talking about what can be effective, but what can be rewarding. YMMV of course.
The only reason I mentioned effective at all is that I don't think it is much fun to be a (knowingly) ineffective leader.
There is, in fact, fun to be found at every level. Perhaps not for every person, but that's life.
The only reason I mentioned effective at all is that I don't think it is much fun to be a (knowingly) ineffective leader.
There is, in fact, fun to be found at every level. Perhaps not for every person, but that's life.
> There is, in fact, fun to be found at every level
Yes, but we are not on HN for such generic advice.
Early in my career I thought that leadership is the end goal and just great, nobody told me that it's a bit more complex. My initial comment just says, guys, it's not getting easier, it's getting harder, much harder. Now we can do a philosophical debate what is fun, what is rewarding, that challenges are rewarding (YES they are) but it's about the fact the managing people is not easy and shouldn't be underestimated, the reward structure is very different than coding and much more complex than eg a k8s cluster.
I mean just check Glassdoor and how many people there hate their boss. It's so easy to f*ck up an org if you haven't any experience.
Yes, but we are not on HN for such generic advice.
Early in my career I thought that leadership is the end goal and just great, nobody told me that it's a bit more complex. My initial comment just says, guys, it's not getting easier, it's getting harder, much harder. Now we can do a philosophical debate what is fun, what is rewarding, that challenges are rewarding (YES they are) but it's about the fact the managing people is not easy and shouldn't be underestimated, the reward structure is very different than coding and much more complex than eg a k8s cluster.
I mean just check Glassdoor and how many people there hate their boss. It's so easy to f*ck up an org if you haven't any experience.
Right on. I'm 71, self-employed, successfully evaded management, have coded all my life and would never have done otherwise.
I have managed fellow coders, but always had my hands in the coding jar. I continue to innovate, and hope to be coding the week I shuffle off this mortal coil.
I have managed fellow coders, but always had my hands in the coding jar. I continue to innovate, and hope to be coding the week I shuffle off this mortal coil.
Wow, what's your stack?
Sorry, I just saw your question.
I do old school desktop, C++, some C#, Win32. Just converted to macOS through Qt.
My target market is firmly entrenched in desktop, for technical and political reasons. I have Web-based versions of my app using REST, XML, and JSON, but they only constitute 3% of my sales.
I switched from COBOL and mainframe Assembler to C in 1988.
I do old school desktop, C++, some C#, Win32. Just converted to macOS through Qt.
My target market is firmly entrenched in desktop, for technical and political reasons. I have Web-based versions of my app using REST, XML, and JSON, but they only constitute 3% of my sales.
I switched from COBOL and mainframe Assembler to C in 1988.
What are your opinions on autonomous team members? I understand that organization is important, but is it possible to have an organization with minimum red tape by setting goals and let team autonomously execute? Would that reduce management burden?
In an org of any non trivial size, no it won't work and it will increase management burden long term because it will damage things. As teams grow, supervision and communication get non linearly harder and less efficient. If you give some rogue the root keys and carte blanche, they may well get sh*t done but will also, almost certainly, cause a lot of problems for others.
Discipline, good hiring practice and clear goals and accountability at all levels are what's needed.
Discipline, good hiring practice and clear goals and accountability at all levels are what's needed.
I don't see much discipline, good hiring practice, or clear goals in history. Why would it suddenly help now?
> - Leading bigger headcounts is comparable to competitive sports 24/7 and shouldn't be underestimated
Would you please expand on this point? What do you mean and how so?
Would you please expand on this point? What do you mean and how so?
[deleted]
Great summary
spot on!
Congratulations on getting as far as you have.
I look forward to reading this, I've been making this transition so I'm sure plenty will relate to me.
A couple of points :
Is there anywhere I can pay for this in pounds?
Your choice of excerpts is very teasing, but I haven't had a chance to read any of the in depth content. Would you consider one of the sub-sections? That said, I suppose they did work for me... So maybe you know what you're doing!
I look forward to reading this, I've been making this transition so I'm sure plenty will relate to me.
A couple of points :
Is there anywhere I can pay for this in pounds?
Your choice of excerpts is very teasing, but I haven't had a chance to read any of the in depth content. Would you consider one of the sub-sections? That said, I suppose they did work for me... So maybe you know what you're doing!
Hey! I think you'll have to wait until the thing is done and then you can buy it from Amazon and other bookstores. Couple of months, I guess.
The publisher is in charge of choosing the excerpts, but I'll feed that back to them.
The publisher is in charge of choosing the excerpts, but I'll feed that back to them.
I've been looking for something like this. Hope it's good.
One thing: the description starts with "Software startups make global headlines every day". That line seems completely disconnected from the rest of the description and it seems nothing would be lacking if you started with the next sentence instead.
One thing: the description starts with "Software startups make global headlines every day". That line seems completely disconnected from the rest of the description and it seems nothing would be lacking if you started with the next sentence instead.
Sure, that's good feedback and makes a lot of sense. I can edit that blurb.
A competent manager is a very rare breed indeed. Competent team leads - I've had a few of those. But at any level higher than that all competence seems to fall away. Success would seem to be despite management rather than because of it.
Do you also deal with the 'why' of moving to the management track? I've seen quite a few people becoming depressed and moving back from the mgmt track to their old position.
I said something similar in another comment, but one of the things I say in the introduction is that I've written the book to help people understand what the management track is really about. So if someone reads the book and decides that it isn't for them, I think that I can hopefully say I've helped them also.
In a lot of companies the “why” is simply about money. There may be a technical career track but it’s really hard to move forward on it compared to the management track. So for most it’s just money. And the jump in salary is often enough to compensate for any dissatisfaction the move causes.
I had written such a book too, but in Chinese, you can find it here if you are interested:
https://afoo.me/books.html
https://afoo.me/books.html
This looks great and I would love to get one. I am interested in the Hard Copy only (I can't do ebooks). Is there a mailing list for the hard copy ?
Sure! Sign up here: https://t.co/burXhyiuoK?amp=1
Well done, this is an area that could use more declarative information and less guesswork. I think there's another question that also needs answering: how do I make myself _want_ to be a manager? A lot of times, the incentives tell the engineer not to bother because the money is already good and you have a decent impact anyway. I'm very interested to hear your thoughts on the subject.
That's a very good question. In the introduction I've said that I've written the book as a way of letting people understand what the role is really like so they can make that decision.
However, I think that I could use a sidebar to the reader to allow them to further question their own motives, and help them make that decision more clearly.
However, I think that I could use a sidebar to the reader to allow them to further question their own motives, and help them make that decision more clearly.
I will keep in on your book. I've read the "Effective Manager" and the "Manager's Path" so far. The first one has some good hints here and there but it's overly verbose and at times feels like a marketing campaign. The second one, I loved and resonates with my experience so far.
Congrats for getting published!
Congrats for getting published!
Thank you! I hope you like it.
In most big companies in Silicon valley, being a manager is not a promotion but rather a parallel track.
What I find strange is that most of big cos expect managers to not be technical anymore. There is that weird expectation that the manager should have been technical in the past but is now only used as an enabler for the team.
What I find strange is that most of big cos expect managers to not be technical anymore. There is that weird expectation that the manager should have been technical in the past but is now only used as an enabler for the team.
Even in silicon valley this is largely the minority. Yes it does occur more frequently here but not to any scale worth noting.
It is part of human nature for leads to gain more than the fair share even when the leads are doing disproportionally less work and less skilled work. This has happened across the board for almost every culture past tribal cultures.
It is part of human nature for leads to gain more than the fair share even when the leads are doing disproportionally less work and less skilled work. This has happened across the board for almost every culture past tribal cultures.
Are there alternative methods on buying your book? I don't have PayPal and I don't have a credit card.
Good question! I don't know. I can ask my editor. When the print copy is out it will be available from bookshops and Amazon and so on, so maybe that's the short-term answer.
As someone who's constantly at somewhat of a crossroads on the subject, this book's intro leads me to believe it's exactly up my tree. However, I would prefer to read a physical book — is it possible to subscribe for updates so I know when it comes out?
I don't know if there's a way to subscribe for updates with the publisher, but if you use Twitter I'm on there as @jstanier and I give updates on how it's going. If you're not on Twitter then I can drop you an email.
I'd recommend setting up a mailing list and promoting it on your site. See the "stay in touch" section at https://dataintensive.net/ or the "sign up for newsletter" section on https://the-cloud-book.com/ for examples.
Yeah, that's a good idea. My blog has a mailing list but I did a wonderful job of making it extremely hard to find.
Question to CTOs - are you happy? When I see what particular CTO does day to day, assuming he/she was an engineer before - it seems quite boring. It seems they've sacrificed their engineering side in exchange for a bigger salary.
The grind of constantly learning the latest technologies eventually got boring, and now I really enjoy managing developers. For me personally, helping an unhappy or under-performing developer get out of their slump is a really rewarding experience.
I don't enjoy long-winded, pointless meetings - but if you're organisation has so many of them, you'll get pulled into them anyway once you're senior enough.
I don't enjoy long-winded, pointless meetings - but if you're organisation has so many of them, you'll get pulled into them anyway once you're senior enough.
> For me personally, helping an unhappy or under-performing developer get out of their slump is a really rewarding experience.
This is a pretty nice approach. Congrats.
Often people are chosen in senior positions because the sell themselves. They are articulate and have "executive presence" and they seem to know what to do, but often they don't. I wish more of them were chosen because they listen, and they knowledgable and thoughtful.
This is a pretty nice approach. Congrats.
Often people are chosen in senior positions because the sell themselves. They are articulate and have "executive presence" and they seem to know what to do, but often they don't. I wish more of them were chosen because they listen, and they knowledgable and thoughtful.
I'm generally aligned with this comment. I really enjoy helping others succeed. I also have a lot of input into the product strategy, and that is very rewarding for me also.
i think i am an under-performing developer. if you dont mind sharing some secret sauce... what are the first questions you think about asking to diagnose whats going on?
What makes you think you're under-performing?
I think the "secret" is simply to make sure people know what they're suppoesd to be doing, that they want to do it, and that they feel they have everything they need to do it. That won't necessarily always work, because not all under-performance is work-related - if you've just had a baby, going through divorce or bereavement, I'd expect you to be 'under-performing' and wouldn't try to fix it.
If you do want a chat, I'm available on email (it's on my profile page).
I think the "secret" is simply to make sure people know what they're suppoesd to be doing, that they want to do it, and that they feel they have everything they need to do it. That won't necessarily always work, because not all under-performance is work-related - if you've just had a baby, going through divorce or bereavement, I'd expect you to be 'under-performing' and wouldn't try to fix it.
If you do want a chat, I'm available on email (it's on my profile page).
thanks, will drop an email (to be clear its not like i was expecting any solutions here, i just like learning about how managers manage).
Great, I'll reply to your email. As a manager, I wouldn't discuss any problems you're having in an open forum - and I'd try to do it face-to-face as much as possible. It takes time to build up trust, figure out what's going on - perhaps you already know but don't feel comfortable, perhaps you need to work it out.
I would look at three things.
- Do you have autonomy in your job ? You need to be able to do your job without having to ask for permission every five minutes. You should also have some freedom on how to do it.
- Do you feel you are getting better at your job ? Every day you need to have the feeling that you are becoming better at it. Is your job hard enough but not too hard. Too many unknowns may cause frustration. Too few unknowns make the jobs too easy and boring.
- Purpose - Do you feel that everyday you are making a difference? You need to feel that you are making somebody's life better.
- Do you have autonomy in your job ? You need to be able to do your job without having to ask for permission every five minutes. You should also have some freedom on how to do it.
- Do you feel you are getting better at your job ? Every day you need to have the feeling that you are becoming better at it. Is your job hard enough but not too hard. Too many unknowns may cause frustration. Too few unknowns make the jobs too easy and boring.
- Purpose - Do you feel that everyday you are making a difference? You need to feel that you are making somebody's life better.
ahh. 2 and 3 are killers. i need to go meditate on this.
to be fair tho, i don't expect most tech jobs to actually have a strong sense of purpose. it's that old SV trope of "we're making the world a better place through minimal message-oriented transport layers".
#2 is a great question. its kind of like looking at the job through game design. its true i dont feel like i'm becoming better and i dont see a clear path to becoming better. I will probably actually use this line of thinking to have a convo with my manager.
to be fair tho, i don't expect most tech jobs to actually have a strong sense of purpose. it's that old SV trope of "we're making the world a better place through minimal message-oriented transport layers".
#2 is a great question. its kind of like looking at the job through game design. its true i dont feel like i'm becoming better and i dont see a clear path to becoming better. I will probably actually use this line of thinking to have a convo with my manager.
I'm not a manager, but I think I might have been where you are now a year ago. My agency and I ended up separating. At the time I felt a tremendous sense of relief, but now, I feel mostly regret because of the potential of that job and how ideal it had been in the first 2-3 years. I miss everyone terribly and wish I could magically go back to the good times because they were truly wonderful, like something out of a dream.
If I could do it all over again, I'd completely omit the technical from my decision making. Odds are that you're probably doing just fine and suffering from something like imposter syndrome. In my case, my billable hours had started to fall, which is the one thing that can't slide for long. I was having doubts about my project and my contribution to it, for personal reasons stemming from my financial troubles after the housing bubble popped. I should have asked for a sabbatical.
Maybe you can step back for a moment and imagine that if the technical needs of the project are being met, what is your vision for the future of the company and the prospects of the other employees? Have some of them been snatched up by Fortune 500 companies? Will some of them benefit greatly by having your company on their resume? Have some of them been able to grow as individuals, perhaps continuing their education or even finding happiness and love? If you feel a resonance with those types of things, you might be surprised to find an interest for it reflected in your own bosses. Maybe they are focused on making payroll and haven't had the support they need to consider those other things. If you have an HR person, maybe you can sway the conversation in those directions. If not, maybe you can talk management stuff long enough that people start to want you in that role. Please don't underestimate vision like I did.
If I could do it all over again, I'd completely omit the technical from my decision making. Odds are that you're probably doing just fine and suffering from something like imposter syndrome. In my case, my billable hours had started to fall, which is the one thing that can't slide for long. I was having doubts about my project and my contribution to it, for personal reasons stemming from my financial troubles after the housing bubble popped. I should have asked for a sabbatical.
Maybe you can step back for a moment and imagine that if the technical needs of the project are being met, what is your vision for the future of the company and the prospects of the other employees? Have some of them been snatched up by Fortune 500 companies? Will some of them benefit greatly by having your company on their resume? Have some of them been able to grow as individuals, perhaps continuing their education or even finding happiness and love? If you feel a resonance with those types of things, you might be surprised to find an interest for it reflected in your own bosses. Maybe they are focused on making payroll and haven't had the support they need to consider those other things. If you have an HR person, maybe you can sway the conversation in those directions. If not, maybe you can talk management stuff long enough that people start to want you in that role. Please don't underestimate vision like I did.
thanks :) i definitely do have a bit of imposter syndrome, although i guess i actively seek it out. "if you're not the dumbest person in the room you may be in the wrong room" and all that.
i have rarely had a helpful convo with an HR person though. always hear the warnings at the back of my head that they're not on my side, they're on the company's side.
i have rarely had a helpful convo with an HR person though. always hear the warnings at the back of my head that they're not on my side, they're on the company's side.
FWIW I've given up on trying to gauge my own performance. I've plainly been disappointing people when feeling like I'm working about has hard as I could. I've (over, and over, and over) been complimented on both the quantity and quality of my output when I feel like I'm half-assing it, at best. There doesn't seem to be a much relation between how I feel like I'm working and what others perceive.
Are you under performing due to lack of competence, or lack of motivation?
probably a little of columns A and B. i guess we're all like that? (we as in underperforming devs)
Sorry, not a manager myself, so I can't help with motivation. But competence can always be gained by practicing. Try a project on your free time. Make an app with ads. The bit of extra passive income can be your carrot on a stick.
haha, thanks for the idea :) i have no problem with passive income (i've done some teaching on the side, it generates passive income, it doesnt motivate me at all) but i do wanna work on a new app.
As CTO I'm trying to incorporate both sides: some hacking under the umbrella of a "Research Lab" and oversight/representation.
I definitely feel the lack of management training.
Being a nerd for decades doesn't mean you know how to lead a bunch of nerds ;)
I definitely feel the lack of management training.
Being a nerd for decades doesn't mean you know how to lead a bunch of nerds ;)
I found the hardest thing to initially get my head around was going home at the end of the day wondering what I'd achieved.
Moving from tangible daily outputs (code etc), to longer term feedback loops can be just as rewarding, you just need to step back slightly.
Empowering others to achieve their potential, watching them grow. Watching great products evolve. Understanding and directly influencing tech decisions. Being able to look further than the next sprint. Interfacing with external parties, seeing how they approach similar / new problem spaces.
IMO, this never gets boring.
Moving from tangible daily outputs (code etc), to longer term feedback loops can be just as rewarding, you just need to step back slightly.
Empowering others to achieve their potential, watching them grow. Watching great products evolve. Understanding and directly influencing tech decisions. Being able to look further than the next sprint. Interfacing with external parties, seeing how they approach similar / new problem spaces.
IMO, this never gets boring.
going home at the end of the day wondering what I'd achieved
Keep a log throughout the day. It helps.
Failing that, use email, issue trackers, repos, purchase orders, inventory logs or other major communications channels / process interfaces to retroactively summarize progress. I currently do this weekly, and use it as input to reporting and planning processes.
Keep a log throughout the day. It helps.
Failing that, use email, issue trackers, repos, purchase orders, inventory logs or other major communications channels / process interfaces to retroactively summarize progress. I currently do this weekly, and use it as input to reporting and planning processes.
Hardly! It's about impact & working with people who complement your weaknesses - think about how much you don't know, even just as an engineer.
A more senior leader I very much respect - when I was about to make the transition - put it this way: "I was doing great as an engineer but had so much I needed to get done, so they helped me put together a team of 4, which was great, because I could accomplish almost twice as much; then it was 30 people and we had a whole product I was proud of. With 200 I know I'm changing the industry..."
You have to learn different skills - how to motivate people, how to see potential conflicts and roadblocks and use them constructively - but the technical skills you bring to the table can make your impact much stronger; and I think I get to learn new ones at a much faster pace at a compromise that I can't go as deep in more than a few spots compared to full-time engineering.
A more senior leader I very much respect - when I was about to make the transition - put it this way: "I was doing great as an engineer but had so much I needed to get done, so they helped me put together a team of 4, which was great, because I could accomplish almost twice as much; then it was 30 people and we had a whole product I was proud of. With 200 I know I'm changing the industry..."
You have to learn different skills - how to motivate people, how to see potential conflicts and roadblocks and use them constructively - but the technical skills you bring to the table can make your impact much stronger; and I think I get to learn new ones at a much faster pace at a compromise that I can't go as deep in more than a few spots compared to full-time engineering.
I suppose its partly how you perceive the work. Programming carbon-based neural networks can be an interesting technical challenge...
I really enjoy getting to influence projects at their genesis, being a CTO gives me a mandate to intercept & triage requirements. Trading off some day-to-day coding for this opportunity is a win for me.
I'd love a blog about how to AVOID becoming a manager as an engineer or technical person. It really seems "contributors" are at the bottom of the pyramid, especially in companies whose core business is not technical in nature.
It's not particularly hard. Just never accept a leadership position :). As long as you keep your technical skills sharp, you should never be short of a job. However your income will likely plateau very early in your career. You can try to become famous as a way to counteract that, but it is substantially harder than just going into leadership.
> However your income will likely plateau very early in your career.
yes this is sad part. hoping AI will take over leadership and only AI engineers will be needed. /jk
yes this is sad part. hoping AI will take over leadership and only AI engineers will be needed. /jk
I can’t wait for it to come out of beta and be available in my O’Reilly subscription :)
I didn't even know that was a thing. :-) Ace!
Jstanier - Great job, this looks really cool. Curious what icon set are you using? I saw you have similar style icons across a few of your projects, is there a standard library you are using or are you creating them yourself?
Hey - icon set? What do you mean by icon set? :-)
Just the images on the front page, guess a bit bigger than icons!
I /think/ I know what you're talking about, but just in case this gets derailed in a back-and-forth and lost, then feel free to contact me on Twitter @jstanier or my email is in my profile - we can chat more easily there.
> If anyone's at all interested ... pitch(ing) a publisher with their own book idea, then ... I'm more than happy to give you any advice
Really? How do I contact you?
Really? How do I contact you?
@jstanier on Twitter if that works for you.
Very relevant to this new team lead (since Autumn last year). I bought a copy, I can't wait to read it :)
Thank you! I hope it helps. Let me know if there's anything you'd like covered.
Man you have a PhD. Is this book worth reading for someone who just have basic education?
I have a PhD. The piece of paper hangs in my bathroom so I can look at it while I shit. It was a personally fulfilling experience that taught me a lot about academic research and and is almost completely divorced from the practice of software engineering management. (and most other things.. I'd suggest never being intimidated by a PhD.) The book is written on a very approachable level, I'm enjoying it so far.
Thank you, I'm pleased you think that. My PhD was in compilers anyway. I have no formal management training. :-)
What is the format of the book? PDF? Epub? Mobi? Html?
Is it / will it be readable on a Kindle?
Is it / will it be readable on a Kindle?
Pragmatic Programmers beta and published books are available as all three - PDF, epub, and mobi (which reads fine on my Kindle).
Great! This is exactly what I was looking for.
Will we get the updates if we buy the beta version?
Will we get the updates if we buy the beta version?
Yes, the betas get updated along the way, and you'll end up with the final print version when it's done.
[deleted]
Have some questions for you. What's the best way to get in touch?
@jstanier on Twitter, or my email is in my profile.
Embrace the dark side Luke.
<3 <3 <3
Clickable links for my fellow loafers:
https://www.theengineeringmanager.com
https://pragprog.com/book/jsengman/become-an-effective-softw...
https://www.theengineeringmanager.com
https://pragprog.com/book/jsengman/become-an-effective-softw...
Last year I was fortunate enough to sign a deal to write a book with my favorite technical publisher, The Pragmatic Bookshelf.
When I started out as an Engineering Manager many years ago, I found that there wasn't a huge amount of material that specifically and practically helped me understand how to do my job. When you learn to program there's all of these amazing tutorials, examples and guides, but what was there for new managers?
In response to this, a couple of years ago I started a blog over at https://www.theengineeringmanager.com which got a decent amount of traction - I had a few front-pages here too, which was awesome. I improved a lot as a writer.
This gave me the confidence to pitch a book to numerous publishers and thankfully my ideal choice wanted to work with me.
The book has now been released in beta, which means you get DRM-free access to the first 240 pages (13 chapters) and more chapters will be pushed out as they get finished. I've written 17 out of 19 of them so far. The hard copy should be out in the Spring.
It's available with free excerpts here: https://pragprog.com/book/jsengman/become-an-effective-softw...
If anyone's at all interested in learning about what it's like to pitch a publisher with their own book idea, then I guess I've been successful at that now, so I'm more than happy to give you any advice. I've had a great time working with PragProg and my editor and the other staff there have been (honestly) fantastic.
I'd love to hear your feedback, and the nice part about the beta process is that the book still isn't finished, so there's plenty of scope for improvements.
Thanks all!