4 ms·

I have been thinking about something else. What is the exact function of a manager other than the annual reviews and hiring? I would like to ask the managers he

I have been thinking about something else. What is the exact function of a manager other than the annual reviews and hiring? I would like to ask the managers here, what does your day to day look like? How involved are you in the technical things your team does?

lanecwagner 6y ago
Author here: this is something I wonder often. In companies I've worked at that had non-technical leadership in the engineering department I'm suspicious that they just played Bloons TD 4 all day. They certainly never seemed to have anything to do other than hire, fire, and go to meetings to have things explained to them.
- curiousllama 6y ago
  That's not it at all - a year ago, we actually defined a new strategic initiative to migrate the legacy userbase to BTD5, and the CEO herself gets regular readouts.
- deleted 6y ago
  [deleted]
curiousllama 6y ago
In my experience: communication. It's the manager's job to keep the big picture in mind: how is this team's output impacting major org goals? If a manager doesn't have the story and line of communication set up (through his Director, etc.), the engineering team could prove P=NP; nobody would notice or care.
deleted 6y ago
[deleted]
yllus 6y ago
It's an incredibly busy position if you're doing it right! I've had development teams of 4 - 20 reporting to me, and I think my responsibilities have generally included: - Being the point of contact between Development and the rest of the organization, fielding questions about what can and can't be done, plus t-shirt sizing on effort - Keeping tooling and technology unified (not ending up with one project each using Vue.js, React, Ember, Angular...) - Keeping up standards (around code reviews, documentation, testing and alerts, end user and developer training) - Thinking long term about how features, services and tools being built today can be re-used tomorrow - Decisions about budgets and how to approach a project (use internal people or outsource to a vendor; field RFP responses; negotiate and get paperwork signed) A lot of communication (inter-team and intra-team), budget work and "architecting" stuff is a reasonable summary, I think.
taude 6y ago
Aligning with product to build the right things on a schedule everyone can live with that supports the inflow revenue via sales deals. Lots of backlog grooming, coordinating with other teams on their dependencies for the team (including devOps procedures and their shared libraries, new core libraries, new infrastructure, new cloud-native technologies we can use). Ensuring that what the team builds makes sense in the context of the whole company (alignment). Reporting up weekly metrics that are translated and normalized for the whole org across all teams in general (things like scrum/product team efficiency), following released product dependencies, writing change logs, release notes. Testing out APIs (which is sometimes like a variety of program management stuff at times). Learning all the black boxes of the system you're building and also all the ones you interface with, or might interface with. Then all the personnel stuff, the hiring, the care and feeding of the team, the one-on-ones, the hiring, the firing. Attending architectural discussion meetings for your own team, but as well as others. Working with MSPs on outsourced infrastructure, costs, some budgeting. Being accountable when a project goes sideways, and coming up with ways to try and get things back on track. Finding resources at the company to help out with something that might be in a gray area that's not my teams responsibility, but something we need, but is something that we're not experts in.... I still try to code a couple hours/week, but it's mostly around the undesirable stuff, or tooling (like CLI-stuff) to facilitate efficiency, generate metrics, help me play with the platform in a constructive way that facilitates my knowledge, etc...
paxys 6y ago
To answer this slightly evasively, the biggest responsibility of a manager is to handle any day-to-day situation that isn't on anyone's job description. If something isn't anyone else's problem, you make it your problem and figure out how to deal with it. Why is a project behind schedule? Why aren't these two engineers/teams/divisions talking to each other? Why is there an uptick of bugs in recent releases? How do you prepare your organization to respond to service outages or security breaches? The ability to recognize and deal with such unknowns is the most useful skill for a manager.
managementthrow 6y ago
Management feels low value sometimes - it's hard to quantify your contribution. At first, I felt a lot of imposture syndrome and wondered if management could be automated. Now I know soooo differently. Having worked as a manager for a year now, I can say: It's way busier than you know! There's a lot of work that happens behind the scenes to keep everything going. The better your manager is, the more invisible this work will seem to the team. I think this is sort of like asking: what does a coach even do in sportsball? They're not a player, why not just have the team do their own thing? It's a different layer of the system that requires a lot of systems thinking and people skills. Here is a list of how I spend my time: - Making sure the right people have the right opportunities to solve the right problems - Coaching individuals on my team on career development - Helping to define organizational topology/structure and interfaces between teams & roles - Manage expectations of those outside the dev team - Proposing & maintaining process documentation - Helping define organization culture & maintain it - Hiring & Interviewing - Architecture, tech debt, system vision, and helping the tech leads make the business case - Facilitating communication between teams & acting as a shield for my team, so that they can maintain focus And then there are things that aren't officially my responsibility, but I end up doing because I do what's needed: - Jump in to help facilitate the team through an incident - Act as scrum master / agile ceremony facilitator - Produce Roadmaps & help define work/user stories when there is no Project/Product Manager / Business Analyst available - Troubleshoot production issues And I know there is so much more. To be honest, I would NOT have enough time to do everything if I spent 80% of my time coding. I'm lucky to get 5-20% of my time coding in! I think the original poster should try Engineering Management for a while to see how busy they get with non-coding tasks. Competencies you require to be an Engineering Manager: - Agile/DevOps/DevSecOps/Continous Delivery/Modern Buzzwords - Systems thinking - Organizational Design - Process design, including things like Lean, Six Signma, Toyota, etc. - Business strategy - Recruiting - Mentoring - Coaching - Public Speaking - Written communication - Product Engineering - Infrastructure Engineering - Negotiation & facilitation of disputes - And the list goes on! A really good book I recommend to try to understand the systems thinking required for management is: An Elegant Puzzle Systems of Engineering Management By Will Larson

lanecwagner 6y ago

Author here: this is something I wonder often. In companies I've worked at that had non-technical leadership in the engineering department I'm suspicious that they just played Bloons TD 4 all day. They certainly never seemed to have anything to do other than hire, fire, and go to meetings to have things explained to them.

curiousllama 6y ago
That's not it at all - a year ago, we actually defined a new strategic initiative to migrate the legacy userbase to BTD5, and the CEO herself gets regular readouts.
deleted 6y ago
[deleted]

curiousllama 6y ago

In my experience: communication. It's the manager's job to keep the big picture in mind: how is this team's output impacting major org goals? If a manager doesn't have the story and line of communication set up (through his Director, etc.), the engineering team could prove P=NP; nobody would notice or care.

deleted 6y ago

[deleted]

yllus 6y ago

It's an incredibly busy position if you're doing it right! I've had development teams of 4 - 20 reporting to me, and I think my responsibilities have generally included: - Being the point of contact between Development and the rest of the organization, fielding questions about what can and can't be done, plus t-shirt sizing on effort - Keeping tooling and technology unified (not ending up with one project each using Vue.js, React, Ember, Angular...) - Keeping up standards (around code reviews, documentation, testing and alerts, end user and developer training) - Thinking long term about how features, services and tools being built today can be re-used tomorrow - Decisions about budgets and how to approach a project (use internal people or outsource to a vendor; field RFP responses; negotiate and get paperwork signed) A lot of communication (inter-team and intra-team), budget work and "architecting" stuff is a reasonable summary, I think.

taude 6y ago

Aligning with product to build the right things on a schedule everyone can live with that supports the inflow revenue via sales deals. Lots of backlog grooming, coordinating with other teams on their dependencies for the team (including devOps procedures and their shared libraries, new core libraries, new infrastructure, new cloud-native technologies we can use). Ensuring that what the team builds makes sense in the context of the whole company (alignment). Reporting up weekly metrics that are translated and normalized for the whole org across all teams in general (things like scrum/product team efficiency), following released product dependencies, writing change logs, release notes. Testing out APIs (which is sometimes like a variety of program management stuff at times). Learning all the black boxes of the system you're building and also all the ones you interface with, or might interface with. Then all the personnel stuff, the hiring, the care and feeding of the team, the one-on-ones, the hiring, the firing. Attending architectural discussion meetings for your own team, but as well as others. Working with MSPs on outsourced infrastructure, costs, some budgeting. Being accountable when a project goes sideways, and coming up with ways to try and get things back on track. Finding resources at the company to help out with something that might be in a gray area that's not my teams responsibility, but something we need, but is something that we're not experts in.... I still try to code a couple hours/week, but it's mostly around the undesirable stuff, or tooling (like CLI-stuff) to facilitate efficiency, generate metrics, help me play with the platform in a constructive way that facilitates my knowledge, etc...

paxys 6y ago

To answer this slightly evasively, the biggest responsibility of a manager is to handle any day-to-day situation that isn't on anyone's job description. If something isn't anyone else's problem, you make it your problem and figure out how to deal with it. Why is a project behind schedule? Why aren't these two engineers/teams/divisions talking to each other? Why is there an uptick of bugs in recent releases? How do you prepare your organization to respond to service outages or security breaches? The ability to recognize and deal with such unknowns is the most useful skill for a manager.

managementthrow 6y ago

Management feels low value sometimes - it's hard to quantify your contribution. At first, I felt a lot of imposture syndrome and wondered if management could be automated. Now I know soooo differently. Having worked as a manager for a year now, I can say: It's way busier than you know! There's a lot of work that happens behind the scenes to keep everything going. The better your manager is, the more invisible this work will seem to the team. I think this is sort of like asking: what does a coach even do in sportsball? They're not a player, why not just have the team do their own thing? It's a different layer of the system that requires a lot of systems thinking and people skills. Here is a list of how I spend my time: - Making sure the right people have the right opportunities to solve the right problems - Coaching individuals on my team on career development - Helping to define organizational topology/structure and interfaces between teams & roles - Manage expectations of those outside the dev team - Proposing & maintaining process documentation - Helping define organization culture & maintain it - Hiring & Interviewing - Architecture, tech debt, system vision, and helping the tech leads make the business case - Facilitating communication between teams & acting as a shield for my team, so that they can maintain focus And then there are things that aren't officially my responsibility, but I end up doing because I do what's needed: - Jump in to help facilitate the team through an incident - Act as scrum master / agile ceremony facilitator - Produce Roadmaps & help define work/user stories when there is no Project/Product Manager / Business Analyst available - Troubleshoot production issues And I know there is so much more. To be honest, I would NOT have enough time to do everything if I spent 80% of my time coding. I'm lucky to get 5-20% of my time coding in! I think the original poster should try Engineering Management for a while to see how busy they get with non-coding tasks. Competencies you require to be an Engineering Manager: - Agile/DevOps/DevSecOps/Continous Delivery/Modern Buzzwords - Systems thinking - Organizational Design - Process design, including things like Lean, Six Signma, Toyota, etc. - Business strategy - Recruiting - Mentoring - Coaching - Public Speaking - Written communication - Product Engineering - Infrastructure Engineering - Negotiation & facilitation of disputes - And the list goes on! A really good book I recommend to try to understand the systems thinking required for management is: An Elegant Puzzle Systems of Engineering Management By Will Larson