How do you insure you are working on the most important items for the TEAM?<p>Whats the thing that drains you the most?<p>Where do you reach out to get advise outside of your company?<p>What is missing from the tools you currently have?
Hard: I have a handful of possible customers for my team, which projects and outcomes will be the most impactful?<p>Harder: I have long term relationships with other teams. How do I maintain those relationships even if every single person on the other team turns over?<p>Hardest: How do I provide opportunities for my individual reports to achieve their personal career goals while also ensuring that all of the work adds up to a meaningful whole?<p>I get advice from mentors within my company. I don't rely on external mentorship.<p>I don't believe that tooling can solve any of the hard problems I have. Management problems are people problems, not technical problems.
(I'm a Director-level with 30 reports in my organization, with a few managers as direct reports. These thoughts below reflect my current problems as well as problems I had when I was "just" an engineering manager. Note that the problems don't go away, just increase in scale...)<p>Number one for first two questions: hiring. Finding solid, dependable people with the right skills and attitude is really, really hard. I probably spend 30-40% of my time on the hiring side of things. We have so much work to do and not enough people to do it, and combining that with the slow rate of inbound high quality candidates means that I have to spend a ton of my time screening and talking to candidates. Someone else mentioned turnover, but I have never (so far in 6 years) had anyone quit while working under me, so turnover for me has been really low.<p>Number two problem relating to the above: diversity. It's nigh impossible to find women and other marginalized groups. They're in such high demand and the supply is so low that it's just so hard to hire people and have your team not look like a team of white dudes.<p>For the third question, I talk to my old bosses and coworkers the most. I have a fantastic relationship with my last two bosses. Nowadays we're peers (same title, different companies) and we compare notes and mentor each other. If you don't have someone like this already, I suggest going to meetups (post-COVID) and meet other engineering managers. A shortcut to this is to find a new job, and then your old job colleagues can be your external mentors ;) That said, there's nothing wrong with having mentors within your company. Just be up-front with them about what you're looking for, especially if they're upper management.<p>For the fourth question, I've never really found that tools have an impact in either direction. I've yet to find a tool outside of Excel/Google Sheets and email that is indispensable.
My main tool for ensuring we're working on the most important thing is simplicity. A kanban board with strong limits on unit size and WIP.<p>Humans are bad at grand strategy. But if I insist that stakeholders order granular units of work by priority and then my team delivers at least a few things a week in that order, I put the questions back into a realm that humans are reasonably good at: I can give you X or Y by Friday. Which one do you want?<p>So honestly, my biggest fight isn't to find new tools. It's to stop people from introducing more tools so that they can sneak unhelpful complexity and the resultant chaos back into the way we work.
Based on what my engineering manager seems stressed about and has his calendar filled with, it is hiring.<p>I'm surprised that the high rate of turnover in tech is not considered a crisis given all the time he spends on that. Even assuming that employee tenure is worthless, a senior level engineer loses 1/3 of his time to this.
1. Being informed about what the top level company goals are as well as department context and goals. If you can't draw a straight-ish line between what you're working on and those goals, it's probably not aligned. Make sure you have a defined and prioritized backlog of projects so that when you have the time/resources, you can easily pluck the next one off of the stack.<p>2. Repeating myself over and over and over (typically ~7 times) to get a message out to the team/org. Even smart people act dumb sometimes, and don't listen/read when they should. It feels like babysitting, sometimes.<p>3. Books, blogs, industry friends, and some mentors. I have found it difficult to make external mentor friends, but still working on it.<p>4. It's never about the tools. Jira sucks, slack sucks, and so do most tools. Make sure you keep your workflow simple and make it transparent, however you do it, so that not only can YOU see what's going on, you can confidently share it with others (see? THIS is why your feature isnt being worked on right now, etc.)
80% of my problems are communication problems. Does X team know about Y team's initiatives and work? Does A team know about B team's weird use cases when they develop their platform?<p>The rest are resource management. It's difficult to hire the "best and brightest" and task them with mundane maintenance and general housekeeping, but those things still need to be done too. It's about striking that balance between exciting greenfield projects and making sure our older services don't rust away.
My perspective is a manager of a product team on an app with high growth. My team has our own backend and we interface with other platform teams for specific functions in the finance space.<p>> How do you insure you are working on the most important items for the TEAM?<p>Push PMs to make decisions on metrics not gut. My contribution is to add engineering and operations toil metrics to our dashboard. Eg. If the onboarding funnel is converting at 90% but our average time to resolve tickets is a week, it's easy to prioritize fixing some bugs over endless A/B tests in the funnel. Have really open and regular dialogue with the team about what they want to work on and where their gaps are, try to put them on projects that help them grow.<p>I also try to have my team interact with other teams as much as possible- customer support, operations, pm, design, other teams. I find it helps give engineers a more holistic picture of the business, the people and pain behind functions and get in the mindset that delivering business value or reducing toil for people can be more exciting than bringing in a shiny new library to our codebase.<p>> Whats the thing that drains you the most?<p>Honestly I have too many direct reports (12). I spend so much time in 1-1s and meetings unblocking people, and despite all my effort the team is not getting as much coaching as I want. I'm an introvert as wells so it's exhausting. I'm working on hiring other managers and organizing us into smaller teams, my goal is to have a 4:1 engineer to manager ratio this year.<p>> Where do you reach out to get advise outside of your company?<p>Mostly I read a lot, blog posts and books.<p>> What is missing from the tools you currently have?<p>I think my main problem is there are too many tools. JIRA hurts almost as much as it helps, slack is a disaster for focus. I'm trying to cut down on tools lately (eg. move out of JIRA, just have a lightweight planning doc with some tables). It works for shorter cycle projects when you have a strong team.<p>One tool I would appreciate is something that keeps me accountable for evaluating performance and giving good performance feedback more regularly. I'm good at reflexive feedback but really deep meaningful feedback takes time to craft, and it's easy to let it slip with the barrage of information in the modern workplace.
Career development for everyone on the team equally. It's hard to shape the project structure in such a way that it fits the capacity while also being highly visible and allowing for growth.
1. Constant communication with users to figure out what issues are impacting them and what they would like to do with the product in the future.<p>2. Trying to convince management to focus on the right things. In practice this is really just me repeating the same thing in meetings and 1:1s until they happen as I gather more and more data from users directly, through analytics and share perspectives from people I manage.<p>3. Other engineers I’ve met over the course of my career. I also try to read for 30 min in the morning. I read everything from self help sorta books to deeply technical books about my area of expertise.<p>4. Having used Jira and Azure DevOps, scheduling tools still don’t seem great. The PM I work with prepares a schedule in excel with me every quarter and we revisit it every few weeks. People look at that like 5x as much as they look at our planning tool and it takes like 1/10th the time to edit or less.<p>EDIT: My team is 4 people including myself. 2 senior, 2 junior.
> How do you insure you are working on the most important items for the TEAM?<p>Getting away from work is the best tool in my experience<p>Managers are self-selected from a group of hard workers committed to the organization. They can want to jump on urgent tasks to shield their teams. This is a great instinct.<p>BUT... it can cross a line where the manager becomes ineffective and begins feeling like they need to do everything, and loses trust in delegating to others to handle these tasks. You can get into a negative "I alone" mindset, where you feel like you have to carry the world on your shoulders. This can be pretty damaging to the manager and the team...<p>So getting away is a way to (a) force others to take on more responsibility thus building your trust in their ability and (b) get away from the urgent, crystalizing what's remaining as the true 'important' ways you can help the team.<p>> Whats the thing that drains you the most?<p>Respond to slack, go to meetings, slack, meetings, repeat... day ends and it feels like nothing got done<p>> Where do you reach out to get advise outside of your company?<p>Honestly, peers at other companies. We have some strong relationships with companies we don't compete with, and we share a lot of learnings about technology we use.<p>> What is missing from the tools you currently have?<p>IMO recruiting tools suck for hiring managers. In my experience, the best devs react more positively to hearing from a hiring manager than a recruiter, yet recruiting tools are built for what feels like impersonal bulk-emailing. As the hiring manager, if I see someone with relevant experience, I just end up sending a real email or LinkedIn message with warm details about why the recruit looks interesting (with real tech details, not recruiter BS).<p>Yet on LinkedIn/Email the contact isn't in our recruiting system... So when they do want to be interviewed, you have to get them in the system somewhat manually.
I've managed engineers at small (series A and B) startups as well as big companies, and I've found the challenges are very different at both.<p>At small companies, my biggest challenge has usually been employee growth/satisfaction and hiring. The saying "a rising tide lifts all boats" is very true at startups. Either everyone succeeds together, in which case even the below average performers will have great opportunities for growth and advancement, or everyone languishes and eventually fails together, in which case even the very top performers may have to go years without any real opportunities for advancement or raises. Some churn is inevitable in most startups when the trajectory of the company is not a perfectly smooth exponential (which it almost never is even in successful companies). Hiring is also difficult, because as the manager you often need to handle more of the process themselves without the support of a recruiting org, and you'll always be at a disadvantage not being able to pay nearly as much as big companies or have the name recognition so closing candidates can be much harder (at least for me, I'm not a natural salesperson so this is something I've really needed to work on).<p>At big companies, my biggest challenge has been navigating the organizational complexity or what some might call "office politics". There is often no shortage of opportunities at big companies, the cool thing is that even modest improvements can lead to huge amounts of incremental revenue for the company. But there are also a lot of things that are less exciting but need to be done to keep the lights on. As a manager, if you have the chance to seek out the former kinds of opportunities for your team and get new exciting initiatives greenlit with upper management, that's often one of the best things you can do for them. Or if the purpose of the team is more the latter category, then it's your job as manager to still make sure everyone in the org understands that this is an important and high impact area, and that you can show clear success metrics of what your team doing a great job looks like. Individual growth and hiring are still important of course at big companies, but there are existing resources in HR and Recruiting that you can lean on to help with it (and there are often strict rules that mean you couldn't deviate from the official processes here even if you wanted to).
The engineering manager's responsibilities vary significantly from one org to another.<p>In some orgs, engineering managers are responsible for all of product delivery - figuring out what needs to be done, hiring people to do it, making sure things ship on time, and making sure the app is always live. In other orgs, they are only responsible for hiring and share that responsibility with HR/recruiting.<p>In some orgs, they are both inward and outward facing - they manage their team and represent engineering in the broader organization. In other orgs, they have no interaction with those outside their direct reporting chain.<p>Some orgs expect managers to report only on a regular schedule. Others have a more "pop quiz" approach to communicating status.<p>The broader the manager's scope, the more concurrent communication threads there are - "balls in the air," so to speak, and the more tools they will have to interact within any given hour. I don't think another tool would help unless it removes the need to interact with others for these managers.
Working on the most important items: automate measuring the most important metrics for your team. Releases, paging events, outages, bugs, support issues. You can look at your data and get a feel for trends and whether you need to focus on quality, or delivering more features.<p>Look into KPIs (key performance indicators). They should be proxies for customer success - Key means only have a few. The engineers should know what they are and be given the autonomy to influence the roadmap and innovate on how best to improve them.
How do you insure you are working on the most important items for the TEAM?
The most important to me are the items that deliver impact for the team and the business at the same time. Very hard to get right 100% of the time.
Where do you reach out to get advice outside of your company?
Previous managers and my own manager.
What is missing from the tools you currently have?
Recording impact over time. How to measure that capacity of work achieved is creating desired results.
I'm curious what the engineering managers here think about code metrics. Things like PRs per week, comments per PR, average time per Jira ticket.<p>Are there statistics of this type that you find useful? If so, I'm interested to hear which ones and why.<p>My current company relies on these sorts of number much more heavily than anywhere else I've worked. There's so much noise that I'm skeptical of their utility, but would be happy to learn more.
My mgr experience is relatively light<p>But I needed<p>1. Better predictability about how much new features would cost<p>2. Ways to limit the soul-crushiness of scrum micromanagement and just management in general<p>3. Easier/better way to communicate upcoming features, and features once they were actually live. Doing weekly product update emails with screenshots was fine-ish but it was a chore that just took too much time, and was it worth the effort/ROI? Eh.
I help run an all-remote team. I'm NOT the "single manager", thank god, I'm not capable of that. Product/eng is about 10-15 people right now. This is my first time in a managerial role but I'm still split between managing and IC work. I worry about a lot of things, but here's the rough priority list:<p>- Do all the engineers know what they should be working on?<p>- Do they know who from the product side they should go to for questions if the specs are unclear?<p>- Do business, product, eng, all agree on what we're doing? Does what we're doing match that agreement?<p>- Are our current communication norms meeting our needs (as little wasted time due to different timezones, working styles, as possible)?<p>- Is the build / test / dev loop fast enough? Are there tools that I need to upgrade / add / improve because we're now bottlenecked? Can we still get away without building XYZ?<p>- Are people happy with the work they're doing and with the people they're working with?<p>- Are people getting to work on things that push their skills and limits in a way that helps them keep growing? If not, is that OK for now?<p>- Are people taking enough time off when they want to so that they're not burning out?<p>- Hiring: do we need to, are we pipelined correctly so that we're bringing new people on roughly when we'll need them?<p>- Are we meeting all of our legal / security needs?<p>- Are we meeting the right amount of the eng needs from the rest of the company, that may not be explicitly product related?<p>- Is my dev work good enough / on time?<p>- What's this new error, is it important, do I need to help diagnose and debug?<p>- I should write a blogpost about <X><p>---<p>The thing that drains me most is trying to do both management/comms work and hard technical work on the same day. I do my best to manage my schedule so I have long blocks of either one or the other but inevitably I'm interrupted. So it goes.<p>I reach out to former coworkers and mentors for advice. Everything I'm doing is based on what I've seen my former managers and team leads do in the past, and I'm so grateful to them for having demonstrated good leadership.<p>I'm not missing any tools. Team is largely happy. We're going to switch to BuildKite to improve build times (currently on Google Cloud Build) for our frontend container, but after that we should be set for a while.<p>I'm thankful to work with the team here at Pipe. I don't need to be perfect for things to work. We all give each other room to experiment. I have never had a more enjoyable working experience.<p>EDIT: we're hiring for product / frontend-oriented engineers, feel free to email me peter@pipe.com if you're interested.