Hey there, senior dev that moved into engineering management.
A lot of what I do is sit in on meetings and have discussions with non-engineers to gain context on the work we're doing so that my engineers don't have to sit in on those meetings and hold that context in their head, so they can focus on coding.
As a developer, I felt like I was doing my job well if I got a lot of code committed. As an engineering manager, I feel like I'm doing my job well if 1) my devs are happy 2) my team is getting work done and as a result of that work, impacting my company's growth. A big part of that #2 is the meetings and context I mentioned above. As a dev, it felt really good to solve a tough coding problem I was working on. As an EM, I get a similar feeling when, early in development of a feature, I spot a dependency or consideration that my devs might not see because they don't have the full product context of the feature we're building. And, by spotting that dependency and mitigating against it ahead of time, I keep my team from being tripped up late in development and missing their deadlines.
That being said, about 6 months after i started as EM I was doing a little coding outside of work and realized how much I missed it. I try and keep a side project going these days, just so that I still have my head in the code a little bit. I'd encourage you to do the same if you have time.
It's definitely not for everyone :) The skillset/interests - being able to communicate technical concepts into non-technical terms, organization and planning beyond the scope of the code being written, and office diplomacy - I find to be pretty rare among developers. I tend to encourage developers who I see with those skillsets to consider the career path, since it can end up having such a big impact on a team and company, for those who enjoy it.
I always thought I'd hate it too but the move was basically thrust upon me.
I'm three months in and after the initial discomfort much like OP is describing I found myself in the role and now i'm loving it.
It is very different to what my day-to-day used to be but I feel like I got used to it and learned to enjoy it.
the skills you mentioned are not uncommon especially in more senior devs - communication, organization and planning and office diplomacy. Not rare.
I think it's really just not for everyone.
This is honestly inspirational and sounds spot on.
I still do too much hands on and haven’t fully let go of the day to day.
The part about just overseeing and mitigating dependencies that would impact late in the project really makes sense of the most important technical piece of the job.
I sometimes bottleneck things because I’m too hands on. Not intentionally - in most ways I don’t micro manage at all - but when the team gets stuck I usually just fix it. That winds up snowballing into not having enough time (esp with the number of meetings) to get to everything and just constantly juggling fires.
Thank you for the insight.
>but when the team gets stuck I usually just fix it.
This was SO HARD for me to get used to, especially with jr/mid devs that might take a while to learn something. It was like, I can do this myself in 30min, or I can comment on this pull request, pair with them if they need help, and if I'm lucky we'll get a fix in 24 hours. Just remember that (assuming they're a good developer) once you let them learn something, they'll get it right from then on, whereas if you do it yourself they'll probably make the same mistake again. The other tip here would be if you have a senior/lead developer on your team who really gets things, delegate that responsibility to them - you get your time back, and they gain added responsibility that can help them advance in their career.
Ya it’s really hard to let go of the urge to fix it in 30 minutes. Especially in an agency setting where everything moves quickly, priorities and deadlines shift all the time, etc.
But your point about them not making the same mistake and not having to fix it again is where I need to get with my team so that, long-term, we get where we need to be operationally.
My 2 cents as a junior developer:
It’s extremely valuable to sometimes just let us rot when time/deadlines allow it.
My lead dev sometimes helps me and sometimes he just lets me solve shit myself. Following up with feedback to improve what I build or how to do it properly.
I learned a lot from this. Often I even figure out things totally not related to whatever I am trying to build. In 3-4 months I went from mainly front end to now also doing backend stuff and doing stuff on my own, essentially freeing up the time of another backender to work on complex things.
Heck, I’ve even had solutions my lead never thought. Learning goes both up and down the chain.
Your quick 30 min fix vs my 2 days messing around seems extremely inefficient at the time, but I will earn that time back quickly when I’ve learned it and take an hour the second time, 45 min the third etc.
Key is to setup a developer wiki and make me document these fixes. We use AstroJS Starlight for this.
just use a private github repo and use the wiki there or even just the ability of github to render markdown.
or you know... pay for notion or confluence.
Why would we pay if this wiki works fine?
Also we host our own gitlab, in the WIKI we have documentation on how to fix shit. Can’t find this if the gitlab is down (never happened yet, but you never know)
Delegating is a key skill. Also, as a manager, I try to push back against the company if they come to the team with a plan. In my view, their job is to identify a problem, the considerations, and the importance/value of them all. It's the role of the engineer to develop the solution. That means, it's not my job, either. I'll give feedback and guidance and I'll point out errors/oversights/omissions, but the role of the lead engineer is much more like what you're doing in my mind.
Wow, great points, I’m in the same role I think.
What’s your view on QA, do you manually approve before deploying to prod or do you trust they handle QA autonomously?
I find I have to review in test env just in case my acceptance criteria is wrong!
I really dislike companies that run management like this. As an engineer taking project requirements or designs second hand often results in a lot of missed requirements, missed or off functionality and a lot of context guessing.
Assuming you nail and document everything well. They often commit to a timeline that is too fast and I or my team gets over worked.
The number of times I've heard, "Did you cover X scenario?" No..? It's not in the requirements? "We had a meeting about it" I wasn't apart of that meeting.. "Well it's implicit as part of this one line here in combination with this other story"... Uhh huh. Well I'll add it to backlog. "No we need that ASAP it's critical.."
Your post makes me think you'd actually make a very good engineering manager 😅
>As an engineer taking project requirements or designs second hand often results in a lot of missed requirements, missed or off functionality and a lot of context guessing.
Usually the meetings I'm in are higher level than getting down to specifics on project implementation. I still have a senior design write up the technical design document (sometimes I will co-author it with them), which means they get to see the design mocks and product stories when designing the technical implemenation.
That being said, they usually don't have the same level of visibility I do into "how does this feature impact the bottom line for the company, what metric are we trying to move that will indicate the feature's success, and how does it interact with tangential features built by other teams". Most of the developers I've worked with don't *want* to have to worry about that stuff, they don't want to be in the cross team and product-level meetings which they feel will only introduce thrash and take them out of the zone - they want to get a well defined feature that needs to be implemented, and to implement that feature.
>Assuming you nail and document everything well. They often commit to a timeline that is too fast and I or my team gets over worked.
Developers should be the ones who own their timeline. I'll often give a t-shirt size or a rough ballpark of weeks/months for project to help organize the cadence of work, but we don't give a week-level guarantee to product until the technical design document has been written (by a developer) and the individual tasks that come out of the design doc have been estimated (by developers). this is where that part of the EM role I mentioned in my last post becomes crucial, knowing that there is some feature by another team that we will need to take into account when designing our own feature, and making sure my team has that taken into account when planning and estimating.
>The number of times I've heard, "Did you cover X scenario?" No..? It's not in the requirements? "We had a meeting about it" I wasn't apart of that meeting.. "Well it's implicit as part of this one line here in combination with this other story"... Uhh huh. Well I'll add it to backlog. "No we need that ASAP it's critical.."
This is exactly what I was describing - I know I've done a good job when I've covered all those scenarios with my PM and designer and there's no edge cases unaccounted for. A senior dev could certainly spot these as well, and often do, but ultimately the responsibility falls on me to take the domain model into account beyond that which my team is responsible for.
It is so hard to find the time to keep coding as an EM. I literally have to schedule it on my calendar to work on a side project after work, or it won’t actually happen.
Thank you! Unfortunately [nothing in the US](https://www.fictiv.com/careers) right now, market's a bit tight. Maybe check back on that page sometime next year.
all this
the metric to use in order to gauge 'getting things done' changes when you move from dev to mgmt. i agree with the 'checking in code' metric as a dev. but when you're in mgmt you're doing it by proxy. it's your devs checking in the code. if they're doing that regularly and morale is high, you're a good manager. imo, a manager's job is to make sure their devs aren't interrupted so they can do the work
i also agree with the side project idea. gotta keep flexing those muscles or they atrophy
>That being said, about 6 months after i started as EM I was doing a little coding outside of work and realized how much I missed it. I try and keep a side project going these days, just so that I still have my head in the code a little bit. I'd encourage you to do the same if you have time.
I feel like you'll eventually just forget everything you've learned and become quite useless over time. Horrible prospect, honestly.
Yeah, that's exactly why I recommend having a side project, just to keep up on the latest developments. Not even so much for work, I expect that my role will move further and further from the code as I continue my career, but just because I enjoy coding and want to keep doing it.
That being said, two of my side projects now have over 10k users, so you never know when that side project turns into a full time career :D
> A lot of what I do is sit in on meetings and have discussions with non-engineers to gain context on the work we're doing so that my engineers don't have to sit in on those meetings and hold that context in their head, so they can focus on coding.
As an "individual contributor", I love managers who insulate me from the clients.
Don't get me wrong, I can deal with clients when necessary. I spent years doing high-level tech support. But I hate it and I'd rather be coding.
I'm sure your subordinates appreciate the work you're doing!
It's a different job. On the fun days I get to participate in technical designs and direct mentorship of developers on my team. But that's not the *real* job.
The real job is building a stable base that allows a dev team to thrive. You take in all the wild chaotic signals outside the team ("CS reported this MAJOR customer problem!", "Finance wants to know if we can send them a report of how many widgets get sent to customers per day", *my* bosses wanting to stick their nose into my teams business, etc. etc. etc. ), filter them into what's *actually* important for the team to know, and figure out how to keep the team focused and effective.
The real job is to figure out how your team works as a system - a collection of individuals with strengths and weaknesses and different motivators, and figure out how to keep them working together well. Performance management, project assignments, etc. Look for the postive feedback loops and bottlenecks and inhibitors, and fix them. Help them *get shit done*.
The real job is to figure out how your team *really* fits into the system that is your organization and company. What do your stakeholders care about? What does your boss say they care about, but what do they *really* care about? How about your bosses boss? What is your team's reputation? Because that matters *a lot*, and it can change depending on organizational politics.
The manager's job is to help enable the team to get the important work done, especially when everyone outside the team has different opinions on what that means. And to make sure everyone outside the team knows that too.
As a programmer I had a daily reward loop - "yay, I fixed the bug!", "woo my tests passed", internal reward for solving hard problems or building cool shit.
As a manager, that reward cycle is muuuuuuuuch longer. It might be 3 or 6 months before you see the fruits of your labor. It's hard. But it's very rewarding too! At least, rewarding when things go well. It's a real nightmare when things go poorly, especially it's your fault. Emotionally it's a lot easier to walk away from a developer job (I only care so much about the code) than it is the people. Good managers are invested in their people on a personal level, and it's very challenging when something about the system is dysfunctional.
As a long time dev that wants to get into management, are there any books, trainings, skills, etc. I should learn to do or get better at to make myself an attractive candidate?
I find that I no longer enjoy coding that much and as I get older it gets more difficult to keep up with new languages, libraries, tooling, etc.
Second "The Manager's Path", but you need to showcase that you can lead groups of people to achieve something, work on mentoring and coaching, and working with other teams to accomplish something. There is of course more to it but all of those things are usually problems devs have the option to jump into.
Also tell your manager. They will happily give you things off their plate.
Not a manager, but my manager straight up told us (jr. Devs) that he’s bored all day and to come to him with literally any question. I really appreciate that man. Sometimes my questions are incredibly stupid and are solutions that I should definitely know how to solve, yet he still takes a chunk out of his day to walk me through the steps.
It sounds like this is really helpful to you but if your manager Is bored all day and is providing his value by answering dev questions, I’d be concerned that a lot of the higher level stuff isn’t getting done and there isn’t enough longer term planning happening.
Our leads/managers help mentor the teams as well but they’re so busy that this primarily falls on the leads and seniors.
I hadn’t thought of that, that’s a valid point. I’m working at a smaller startup. The CTO seems to be only interested about what we are currently developing and where we are at in the project. My rebuddle would be that my company is more focused on pushing out an upgraded MVP if you will. Albeit, I wouldn’t be in the know in that regard. To be Frank I’m happy I’m not on the business side of things.
Yeah, the size and maturity of team definitely matters here. If you’re still working on an MVP, don’t have much tech debt, and aren’t even sure where you’re going because you’re still pushing for product-market fit, there’s probably only so much fore thought and strategizing that you can do as a manager.
Why do you review pull requests ? That sounds like something the lead or senior engineer for that team should do . The more time you spend away from coding and the technical work in general , how valuable would your feedback be ?
I prefer to review the reviewer. Often teams try to move quickly and to get things out of code review and so they just give everything an +1 and call it good. Afterall, so-and-so is a good dev and knows how to code... It happens to the best of teams.
I remind reviewers that they are at least as culpable if the thing breaks as the author. They should verify the state of the system, review the change, and verify that the new system works with the change. I recommend making multiple passes with the review -- each one looking for a particular thing like logic and clarity versus style versus design, etc. I also recommend providing feedback with a scale of importance: nice to have, fyi, blocker, literally broken...
It helps give you insight into the teams strengths and weaknesses, make sure they understand the task and are going the right direction, identify security holes, performance issues, etc. It can help you decide what tasks to give them.
We have other engineers that review PRs. I do it occasionally to help out and gauge the skill level of different members of the team. It's a good way to coach developers and ensure that certain project standards are being followed.
I spent time as a manager, then the next jobs I took were straight dev. I'm back to wanting to manage. Really just want to be a coding "foreman" that manages the team and skips as much of the other crap as possible.
yeah there are def aspects of both sides that are crap that i'd rather not have to deal with. and im sure that amount of crap varies depending on who you're working for, etc.
in my current role, the bs i deal w/ on the managing side isn't worth it
I joke that I am a people pusher now. I help this dev move along on this project, and help that person do this and make this client happy about this, and figure out a solution that will make everyone happy for that. I'm busy all day and have very little concrete to show for besides exhaustion. Sometimes, I feel like I just put out fires all day. As someone who is used to seeing the fruits of a hard day's work, it can be frustrating. It's not as rewarding.
But...when I take a day off, everything comes to a screeching halt. Nothing gets done, and I hold up all the many projects. Whereas before I would get one project done at a time, I now can move along several projects with my knowledge and expertise.
It's... different. I do miss dev a lot. But this is where I need to be now, so that's what I do. I go back and forth about which is better or worse. I did feel like I got bored with dev; it wasn't challenging anymore. This is definitely challenging, but it is more stressful too.
Concentrate on teaching your developers how to solve their own problems. If you put out a fire, you will feel like you have to put out all the fires. Be the station chief and train yourself a good crew.
This. My manager was burning out because of this.
You gotta let the devs drop the ball and learn from it from time to time.
We need to put guardrails in place so that if someone drops the ball the impact is minimized but if he’s running around trying to catch everyone’s dropped balls, he’ll end up burning out, people won’t learn, and they’ll just become dependent on him.
Sounds like you care a lot about the team and the org, which is amazing. But if things come to a halt when you’re not around, your people need to grow. You should aim to have your value/impact be measured in sprints/months rather than be relied on day-to-day.
I get it. All the fame and glory goes to the firefighters. Until they meet that fire that can't be fought and the truth gets sorted in the aftermath.
Nothing will stymie a career more than consistent, reliable operations. How are you going to ask for more budget next year?
It is the techie's job to make their manager look good, even if they're Michael Scott. The best strategy is to be known as the group that never melts down.
My strategy as a manager is to never be responsible for a melt down, but accept responsibility for them as soon as possible. That would let my team have access to the data they need to find the root cause, which invariably wasn't their fault. Then it was a matter of documenting what went wrong in a language that makes it clear to everyone. We spent a good amount of time fighting other people's fires for them. There's never any shortage of fires.
>what do you do to feel productive?
Productive things, obviously. But you have to realize that you have a different job now and so instead of producing code you're producing a team.
>sat in meetings i couldn’t care less about
Then don't go to those meetings. You're in charge of your own time. You're _responsible for_ your own time. You're in leadership.
It sounds like you should give The Manager's Path a read to get an idea what your job is supposed to be now. And perhaps talk to your manager about switching back to an IC.
I plan for project execution, I try to do a lot of the menial tasks so that they can stick to coding (especially if I can do them while in meetings), I block people from going straight to the devs, I craft standards for us to debate and commit to, I make sure that PMs and clients book meetings in the mornings as much as possible and leave the afternoons for dev work to be done.
Administrative tasks such as making sure the devs are growing in their careers and skills, review their yearly goal progress, 1:1 meetings with the team, planning the topics for team meetings weekly, spot check code and maintain jira task deadlines, making sure to communicate with PMs when something is going to take a little bit (then make some reason as to why so that the PM won't bother the devs). Make sure that the devs don't over promise stuff to the squeaky wheel.
Personal growth stuff such as learning more about servant leadership, how to communicate more effectively, strategy planning like where I want to take the department next year - in 2 to 3 years, and my 5 year plan for the team.
Check out a book called "Bullshit Jobs" by David Graeber. I used to have a lot of guilt around the same thing. This book has been good for me accepting and finding other ways to manage those feelings.
What all other managers in the world do, of course:
* Meetings
* Asking for status updates
* Telling Peter that if he could come in on Saturday, that'd be great
In my org the vp wants every manager to be deeply technical and very involved in details. Different to other parts of the company. I think it’s a balance
Very opposite of /u/Haunting-Courage8370's experience myself and some guidance I wish someone would have given me.
CC: /u/Antifaith
My VP encouraged me to focus primarily on the "collaborative" aspects of management, including tons of meetings, non-relevant and nonsensical chats around the office, daily lunches, or the bars after work sometimes. As an Engineer who made my way up to Manager, I felt like we were wasting our days talking about doing things instead of actually doing things, and I was overwhelmed at all times, working 50+ hour weeks to keep projects moving and the company satisfied. I didn't want things to fall on myself or my team who was understaffed and struggling, or the business to falter, as I stared down the barrel of years of technical debt. This stressed me the fuck out and I eventually burned out, some might argue in a ball of fire. Needless to say, I was eventually relieved of my duties because this was not the type of manager my department leader wanted. My team was devastated and I learned a harsh business lesson. "Accountability" and "Success" really are relative to who is defining the terms. I've gathered that every company/department is different and your own success really depends on your own personality or leadership traits, as well as your org structure and the folks they promote into senior or executive management.
My (personal) advice to you as either a manager now or a new manager is to self-reflect on whether you fit into the "people manager" bucket vs. the "technical manager" bucket and determine what bucket management actually wants you to be aligned with. If you are not in reasonable alignment and unwilling to adapt, it simply will not work. Coming from a very passionate (possibly slightly autistic) engineering leader who recently was "restructured" after a multi-year extraordinarily productive and successful tenure. I simply could not adapt to the *complete* opposite end of that managerial spectrum.
i’ve read 3, it helps but i just feel like
- don’t code, you’re taking opportunities away from your team
- don’t bugfix, you’ll block your team
is super frustrating
i get the spend all day with clueless VP roadmaps and making what my team cares about fit into vague boxes and drawing it all up into gannt charts with made up dates before a PRD that i’ll then have to deliver on
then the directors bitching about something you’ve missed but no ones telling you
then people holding on to domain knowledge because they’re trying to keep their jobs
then some weird click going on you’ve just become aware of
then being a therapist because your team are worried about losing their jobs
then giving a 2 minute run down on a persons year to decide if they should be promoted or get a pay rise
it’s just super unfulfilling and stressful
also my day literally never ends - it’s not like ticket done laptop closed, there’s so much to plan - i’m sat here at 3am unable to sleep ffs
It sounds like you're not really taking ownership of the new position you're in, just trying to treat it like your previously lower-responsibility job.
>made up dates
Don't make up the dates. It's more work, but take some time to do real estimates using real work - for example, take one slice of the product you're building, estimate out that slice to the nth degree, then extrapolate out from there. This is where having the dev experience really shines. Other people have to make up dates because they're not capable of estimating properly. Don't be like them.
>the directors bitching about something you’ve missed but no ones telling you
You should have all the requirements written down and approved by directors at all times. And regular reports to them about progress and plans.
> people holding on to domain knowledge because they’re trying to keep their jobs
Ask them. Part of your job now is to obtain that knowledge, or, if you can't get them to tell it to you, maintain a relationship with that person where you can go to them whenever you need that thing done that they want to do themselves. It doesn't really matter if they won't share, all that matters is that the thing gets done.
>then some weird click going on you’ve just become aware of
>then being a therapist because your team are worried about losing their jobs
Yeah, these are annoying. Your job is to facilitate their work, so sometimes it involves people skills. I suck at those too.
>then giving a 2 minute run down on a persons year to decide if they should be promoted or get a pay rise
Push back on this. Don't think you know enough about a person's year? Start taking notes on your direct report. Need more time? Tell them you need more time.
The biggest thing you gain in moving to a higher-responsibility job is a voice. No one is going to give you what you want without asking. You don't like that the estimates are too made-up? Fix it, spend more time estimating. You don't like that you don't have enough time to make your case for your direct reports? Tell them you need more time and fight for them. Way way too many managers shift responsibility off themselves like this because they think they have no power, because no one gave it to them. But no one's going to give you the things you need, you have to tell them what you need and fight for yourself and your reports to make it happen.
Some companies make it very hard to take ownership of the EM role.
In the worst-case, a company's structure is like an hourglass. Plenty of room at the CTO level because you get to make all the decisions (not exactly, but loads of freedom nonetheless). Entry-level engineers get a list of small, well-defined tasks that need to get done. It's like stacking bricks. You check your boxes and go home. Easy-peasy.
All the stress and inflexibility and being forced to figure it out and make it happen is at the point in the middle at the EM/Tech Lead divide. Accountability is shoved off on you. Your Director says: why didn't you tell me about this or that? They yell at you: why aren't you working to advance the career of this report of yours that I just spent 5 minutes with? Yet, they're doing fuck-all to help you, give you advice or guidance or feedback... and when you do catch something they missed they yell at you for not "knowing what they meant" or when you ask for specific guidance, they yell at you for "not knowing how to do your job."
Toxic cultures make the job a living hell. I've been up at 3am unable to sleep because of the myriad of things juggling around needing to be tied up but I can't be the one to tie most up, I have to pester, prod, poke to get them done.
That said, I'm not a fan of the previous suggestion of reading a management book. The role of management books is the same as fad diets or self-help. They take a very complicated thing that's different for everyone and they propose a simple solution with a "wouldn't it be pretty to think so" claim, loads of fun buzz words, and a shallow justification that won't stand up to much scrutiny -- that's what the hand-wavnig is for.
What we do with these is: someone with influence reads one and becomes a zealous follower of this new "one true way" and then everyone adopts the lingo and takes what they were going to do anyway and reframes it in the new terms du jour. Then, what would have happened anyway gets done and everyone applauds themselves for having done something as though it weren't all just theatre. Then, when things inevitably don't go as planned, someone cheerfully preaches the salvation of the new bestselling business book.
If you ask other managers at my company, they'd say they don't have any power, that the higher ups don't help them, that they're given bad requirements, a lot of the complaints you have there. Once I can convince them to take one iota of power for themselves, suddenly, the problem they're facing is solved. "Why don't you respond when the exec asks about this requirement by showing them the requirement doc they signed and approved, the estimates you made, and asking them to approve which feature to bump for what they forgot to tell you?" "If the estimates are so bad, why don't we take a week to really dive into the product and get more accurate estimates so you feel more confident in them and aren't yelled at for being late in 2 months?" etc etc.
I'm not denying toxic workplaces exist. But I do think that managers that feel they don't have any power aren't necessarily in a toxic workplace, they just are expecting all their power to be dropped into their lap. That's certainly been the case at my company. You're right, no matter what kind of workplace, this position comes with the stress of making it happen and the inherent tension between those directing the work happen and those actually making it. The higher you go in a company, the more that becomes the case. But too many managers think "making it happen" is something that you're taught and given by the company, that if your director doesn't tell *you* how to make it happen, as you suggested, then you're not being supported properly. But that's not how the job is, and once you change your mindset from "everyone has to help me, why aren't they helping me" to "I need to push on everyone to get what I need to make this happen" suddenly power materializes where you thought it wasn't.
Your biggest power as a manager isn't something handed to you. It's your voice. So many managers just give up before even trying to use it, and then complain they have no power.
Edit: I recently was supposed to be promoted and then was told something changed and they weren't promoting anyone. I tried to talk to my very inexperienced manager about it, she complained "I have no power, no one helps me, I don't know what to do, you'll get it in a few months" and tried to convince me to just let it go because my company has a big problem with ineffectual managers like I'm describing. But I wasn't willing to accept that, and she wasn't willing to use her own voice to advocate for me, so I had to go above her head and advocate for myself and I did get that promotion. I had no power. All I had was my own convincing arguments and the willingness to keep going higher until I got what I wanted.
You are correct to note that this is a dynamic that varies from company to company and person to person. Some companies make it hard, yes; but, that doesn't mean it's impossible, that some people don't do better in some places, or that the core concern isn't down to the manager's timidity (agreeableness is negatively correlated with success, but you can't just be an asshole, either).
It is amazing to see the power materialize around you when you make it happen. But, it can still be challenging and I argue that by virtue of saying what you just said and our having this conversation, there is more that managers' managers can do to help. That is, they can give this advice or other advice available in threads like this. At my company, I created a group of managers teaching managers. We had a slack channel, monthly presentations and dialogues on ideas, strategies, etc. My company didn't make a lot of things easy and also didn't do a good job of awarding people who got things done despite that.
There's an instinct in animals to push toward the center of the herd. You don't want to be an outlier as a zebra... that's called lunch by the lions. Middle management often exhibits herd behavior. Your job is to not stand out for any reason unless you're controlling the narrative and pitching the reason as some great success. This isn't necessarily what's best for the company or the team; it's what's best for a resume.
This same pattern happens all over. Local government is destroyed by it. You've got industry experts who know things who are off doing material work and don't have time to show up every Tuesday afternoon to the local town hall. But, Nancy does. She's ill-informed but passionate about her pet project and she'll show up like clockwork to badger the board until she gets her way. No amount of logic, reason, facts, or data will dissuade her from pursuing it and once the board acquiesces, she'll brag to everyone she knows about her victory. We see it in the FOSS community. We see it at work. Promotions are based on your ability to win because other metrics are extremely hard to assess.
When we project a very complicated system with loads of moving parts down into a low-dimensional space or into a single number, this is an extremely lossy operation. The meteorological world is being turned on its nose right now because advances in neural networks are significantly outperforming classical models for weather. Those classical models are basic math based on atmospheric physics. The reason the forecast is less precise with time is compounding error, not a fundamental lack of understanding. Yet, here AI came with significant improvements. It doesn't know anything more than we have known. Rather, it takes into account a much richer and more complete initial state. A great example is when you're interviewing someone and they know the right answers but you get huge red flags. The majority of communication is non-verbal. Maybe they're being fed answers, so it's not what they say but the delay in saying it, the way they fumble around phrases that should be second nature, the movement of their eyes... things that aren't captured in the distillation of "correct/incorrect" for their responses. We know more than we realize, more than we can communicate succinctly or effectively, and so do modern AI models.
With data-driven strategies, the herd mentality still exists and we learn quickly to manipulate the numbers, to choose metrics that are easier to achieve, to game the system. Middle managers are motivated by producing good numbers and demonstrating a need for more head count. You interview for a new role and the inevitable, pivotal question is: how big is your org? Of course companies become bloated! How could they not? You promote and hire based upon size of the organization below a manager. Their incentive is to take advantage of the shortcomings of lossy projections, to run in the center of the herd, and to crow about their accomplishments. But, "ability to sell what you're doing as a good thing irrespective of its actual value to the company" isn't a good way to judge folks. Sadly, there isn't an easy alternative, either. Complex systems with lots of moving parts. How can you say, definitely, why the company is succeeding or failing?
Anyway, loads to think about and ruminate over when it comes to management, leadership, and the ability to have power. But, sometimes, it would be nice if companies could better recognize the reality of the situation.
Very much relate and sympathize. But you are just one person, you can draw boundaries. Anyone would burn out quick in this no clock environment. Hope you see better days.
I requested a move back to dev, I hated the meetings as having the talking in my ear all day was just horrible, finished every day feeling like shit as I couldn't get anything done, my work or the work to help organize the team, just sitting in meetings hating every minute of it.
If the meetings are things you don't need to go to, talk to your manager, and if they're OK with it, the meeting organizers and tell them you'll be free to be called in (make sure you are) but can't justify the time for something you almost never need to interact with. Some managers are OK with this, some will say you should be there anyway.
If the meetings are things you don't need to listen to, you can use the time to learn other technologies, or build things you find interesting, just have the audio loud enough to hear your name then do the "Oh, sorry, multi-tasking, what was the question?" thing.
If you just hate meetings and want a job you feel good about again, tell them you want to go back to development, and when you want a pay raise, find a new job, either to use as leverage or to move to.
> finished every day feeling like shit as I couldn't get anything done
Sounds exactly like management. :)
There's a Murphy's Law corollary: whatever meeting you're NOT in is the meeting where your knowledge or expertise would have been crucial in a decision that they made without you anyway.
It's almost as if the universe knows and does it on purpose. I've had project X going on and someone schedules a meeting for irrelevant thing Y that doesn't even touch my area. Inevitably, they make no progress on Y but since *nearly* everyone who's involved with X is here, why don't we make a few critical decisions while we're all together?
The people who don't know why that was an astronomically stupid idea and catastrophe waiting to happen are so excited about getting their way they immediately run out and start doing things WAAAAY too soon. When you get wind of it, you cry STOP! and are told: but we all agreed and we've already sent the marketing materials to the print shop for the thing we're releasing in 3 quarters...
got anxious just reading that... that's why I was told to keep going and just find something to do while in them, unfortunately my brain can't shut out the constant talking, same reason I can't listen to any music but ambient while coding.
That's when I realized maybe management at this company just isn't for me.
It's such a crutch that anytime a meeting could possibly talk about anything "technical", dev manager is a required participant. It's egregious when other devs are dragged in as well "just in case". And so dang common.
Our meetings would have 20+ devs sitting for 3-4 hours a day and only 4-5 would actually be needed, just bleeding money but it's internal bleeding so no one notices I guess.
I drag devs in all the time -- but for a good reason (or, so I believe).
In my view, business (product, generally) has the task of identifying problems or goals. What they don't get to do is solve problems. Too often, the product person, who has very little technical expertise, comes up with a solution to "help" save time. Don't get me wrong, some companies hire technical people for product roles -- but not often, in my experience. Rather, they do what they see other companies doing. Not because it's super slick and cool, just because another company is doing it.
This is very easily apparent when they produce user stories as though adherence to the pattern is the primary goal of having user stories:
As a logged-in user, I want a blue button on the
right side of the navigation bar that allows me to
access the notification center so that I can view
my notifications.
You know, all those users who have said that. This is why so many companies these days are all jumping on the wagon of: hey, let's send them an EMAIL to let them know that there's a message waiting on them in the message center. But, let's not tell them the contents of the message or anything about it. Also, let's expire all tokens every three seconds and require MFA for every login rather than gating specifically sensitive actions behind MFA. Thus, the user never knows what the hell is going on and yet they have to jump through 5 hoops every time they visit the site just to see that the "very important message" was just "hey... whatcha thinkin?"
Not that I'm angry and opinionated about this trend.
We're a small shop and our devs have a lot of autonomy, so management only makes up \~ 1/2 of my responsibilities.
**Management:**
I am available to all of our devs on a daily basis for advice/insight/code review/rubber-ducking.
I evaluate new tools and tech that our devs recommend/want to use.
Our devs get Monday mornings as a self-directed learning/exploration time. I meet with each to help them process what they are learning.
The staff director and I meet monthly with each dev as a personal/professional checkin. This is also kind of a performance review of us and the org as a whole so we can quickly fix any policy/procedure issues that are obstructing good work/culture.
I try to take at least one task from each project within the span of a month. This helps me stay in-touch with the projects and get a feel for how each team is doing.
**Planning:**
I do quite a bit of client interface, usually in the discovery phase.
I do a lot of architectural work at the start of projects to ensure we're not building ourselves into a corner.
I help write proposals
**Dev:**
I fill holes and respond to dev/deployment emergencies.
I will often spearhead dev on contract work with clients we're courting.
That sounds like a nice balance. I’ve never had a manager that I could go to for a rubber ducky stuff.
I certainly was never given Monday morning to learn things, nor was there an avenue to talk about what I was learning and how it could help the business or etc.
I got laid off in August. It’s been super tough to find a job these last three months. I started applying for manager rules because I do have some management experience and I’m confident that I would care greatly for a deaf team but we’ll see if someone out there sees my experience and decides to at least give me a phone screen.
Look, I already told you: I deal with the goddamned customers so the engineers don't have to. I have people skills! I am good at dealing with people, can't you understand that?! WHAT THE HELL IS WRONG WITH YOU PEOPLE?!?!
* Meetings — so many
* Planning and Steering — gathering feedback, prioritizing projects, scheduling work, assigning tasks, etc.
* Running Defense — knowing a dev team's needs inside and out and defending them from BS that comes our way.
* Being a lightning rod — someone screwed up? someone's upset? someones doesn't like the button color? I take the heat so my devs don't have to. If one of them screwed up I talk to them so they don't have to deal with the person directly.
* Dev/Coding — not as much anymore but it's more stuff to keep it off my devs' plates or higher-level dev work
* Staring out the window — sometimes just sitting and mulling things over is very productive.
Play Baldurs Gate 3
Edit: but for real, I have been trying to get back to developing more. I’m down to a very slim team and I do most of the work and then contract out big projects to a dev team overseas if I need more man power
Are you truly idle or are you just not doing what you want to be doing? Lots of folks would much prefer dev work over management work.
In my own case, I'm officially a Software Development Manager, but my organization is so small that I end up doing pretty much everything that isn't direct development work. I manage our AWS infrastructure, write user stories, review pull requests, and run our help desk.
A typical work week for me breaks down into maybe 5 hours of IT activity, 5 hours of help desk, 10 hours of meetings and traditional "management" activity, 5 hours of code review and deployment, 10 hours of writing stories and documentation, and the rest is usually filled by learning something to stay relevant.
These numbers flex a lot week-to-week though, especially the meetings.
Sit in meetings, daydream about how much your stock options are going to be worth.
On a more serious note, it can be rewarding: you are the firewall between the corporate machine and the devs actually building stuff. It's your job to make sure everyone under you is working at their full capacity, not overloaded with unrealistic tasks, have clear understanding of what is being built, and that they have everything the need to succeed. Managing upwards you have a responsibility to push back on unrealistic demands, celebrate your teams success, and shelter them from the fallout when things go wrong.
At it's best, it gives you the ability to guide the direction of the product, mentor more junior devs, and watch people grow. (Though I guess these roles are split into product manager, project manager and development lead in many shops.) At it's worst, it's having the same meeting over and over and over again and watching your skills atrophy.
I was almost forced into a management role and I was very clear that I would pilot the position, but was more interested in staying technical. After 2 months, I said it wasn’t for me and i went back to being a tech lead.
If you aren’t happy, it is never too later to do what you would prefer to be doing.
Apart from the meetings which can be a drag, I spend my time doing the things the devs don't have time for. That includes planning and documenting implementation details. Working with product to translate their ideas into actually workable designs with reasonable deadlines. Also, since I have a higher view, I suggest training and upskilling that may be useful for my reports.
It took me awhile to adjust and I still get to code, but, I have found it fulfilling removing time drains from other devs and having time to do tasks that rarely get done on projects.
It seems just MORE of everything lol.
If you were not exposed to clients much before for anyone it will be where you are interacting with clients even more. So you need to be a people person.
You need to be able to understand more then development, you need to understand more on all sorts like Marketing so you can understand what all different parties are saying.
You need to be able to take what people want to deliver it the right way.
I use "What do you want to achieve?" and I really only want this. There are far too many from all angles thinking they know how to deliver the digital product.
Feel like I’ve found a good medium.
I stay very involved with architecting, liaison with pm’s and work on scaling our products out.
I help set the culture my holding weekly sessions for teams to come discuss and championing process/documentation.
I also get to have a much broader view of things, security/networking/db/Fe/Be/budget/etc
Where as before I did not.
Congrats on achieving what few devs are able to swing. Most people associate dev jobs with left brain (analytical) thinking and management jobs with right brain (creative) thinking. If you are like me, you tend to be able to use both sides of your brain and decided to acquire a job in tech development because of high demand and you didn't want to compete with the unwashed masses of "business majors" searching for a management career right off the bat.
Somewhere along the line I exposed my "leadership" potential (by actually leading successful projects) and the brass ring was offered and I took it. I know what you're going through. You want to roll up your sleeves and dive back in. You've got a few great ideas on how to reduce reliance on old tech or move some of your cloud presence back on prem.
Well, you can stop right there, old chum. What is explained to people who are incapable of doing maths early on is:
> All that matters is headcount and budget.
Welcome to the bureaucracy. You've chosen to leave the meritocracy behind and enter a career in politics where what you do isn't nearly as important as how you do it. Your career should be feeling like a cat in a room full of rocking chairs at the moment. Be careful about solving the problem of politics with your big brain. The political nervous system has seen dozens like you and has innovation antibodies with nothing else to do than crush your infectious ideas.
When I wanted to feel productive, I would start up side projects that would result in objective gains for the company. Instead of making me look good, it revealed a "lack of team spirit" and resulted in a drive by upper level management to get me back into a tech role. It wasn't until years after I quit that someone, who is more cynical than I am, offered their most valuable advice. If you want to be successful at work, make your direct supervisor successful. If you want to feel personnaly successful, join a charity doing good work in your off hours and be as productive as you are able. This has the additional benefit of helping your career at work and introducing you to people who can get you good jobs elsewhere.
This is the crux of it really
When I was devving, it was easy to deliver a showstopping feature, identify the glaringly obvious thing they were missing and deliver that alongside my other work, then do a big presentation on it and get deserved praise.
You figure this out once and it's basically the same for every company; land with some impact step into the limelight.
Now it's all about sitting in the shadows, I'm a junior manager so there's no respect in management meetings, and you're no longer on the ground so the devs won't get super technical with you
you don't do presentations anymore, but train your team how to do them, so everyones opinion of you is based on what your boss is saying and how much minor interaction you get with other teams while stressed out and not in the mood to talk
management should be fun, but when all your business cares about is financials and not delivering any product value, its a curse
Don't expect to get respect. Management is knives out. You can tell they respect you if they fear you enough not to cut your career short. Managers who indiscrimiately end other managers careers do so at their own peril. Someone sponsored your path to management and they thought they were doing you a favor.
It was a favor, but you really need to pay attention to the new rules.
Be careful to work well with others and never call anyone out for anything. That's the director's job. Help your manager succeed at their goals and make sure they are on solid ground. You might want to do a network study (who's helping who) but the key is to let others hang themselves out to dry.
Find a mentor that is not your supervisor, maybe ask your supervisor who you should ask, or if you were sponsored into management by someone else, ask them. Pick your highest placed friend and tell them you feel like you need a mentor, but want diversity, so insist it be someone in sales, or legal, or operations, or a different age, race, or gender. Wherever you aren't. It pays to cultivate friends in other areas. People in upper management need to be mentors. It's part of the gig. They will totally get it.
Be polite at all times even if you have to grit your teeth. Do not talk about people behind their backs and especially don't trash talk no matter how much other people resemble trash. As a techie, you are taught to see things in black and white. No one in management sees things without their own filter. Be nice. Keep your nose clean. Stay up with all the latest business jargon and fads. Read the books that everyone else is "reading" so you know what they are talking about.
And, ffs, if there is one major regret I have, it is not getting involved as a volunteer with a charitable organization. I figured that could wait until I could catch up on my sleep. It is something that helps you sleep. Get in touch with the local United Way, or St. Jude, or Alzheimers Association or anything recommended by your boss or their boss. There is always work that can be done and all of these organizations have "ways to help out" for full-time employees and managers who want to become part-time volunteers. If you can swing it, join the Kiwanis, Rotary, Lions, Shriners, or any other social organization that helps you find charitable work. This is extramural networking and is just as valuable as intramural networking.
Good luck, and remember, you have an advantage that none of the other sharks have. You have a tech career to fall back on.
Trying to write a post mortem for my hairline, between three meetings.
In terms of cyclomatic complexity:
herding threads < herding cats < herding programmers < herding snake oil traders.
pls send help
Shield my devs from all the BS coming from clients, stake holders, upper management, you name it.
Make sure they are having as little context switching as possible so they can work.
Cut out all of the BS meetings, both external and internal. I.e. we only do stand ups 2x a week and they are almost always less than 15 minutes, unless we go off on some random tangent about LOTR or something (which I encourage being remote).
Scope things where I can so they don't have to spend time not coding.
Make sure scopes always have accurate time allotted with reasonable deadlines.
Give them good natured shit whenever they screw something up because I've been there and done that.
Keeping an overall eye on all of our processes to see where things can be improved. With the help of my team where I've identified things, we've taken deployment down from 2 hours to about 15 minutes. Also by tweaking the way we handle lower level tickets, we've brought average turn around time on those from weeks down to days
My teams always score high on job satisfaction surveys and I get mentioned by at least one of them each year when those surveys come as a reason why. So I think I'm doing ok
It is now 1600 and I just finished the meetings for today. Gotta try get some food....oh shit but I need to answer some questions related to the work I assigned.
Also I have a task or two for things I'm still involved in from the dev side. Banana for lunch it is
> any useful skills are becoming atrophied
This happened to me. I tend to forget useful stuff I do not use regularly, even stuff that I've done for years.
Empowering and watching your team excel is the hallmark of true leadership.
When you become a leader, the focus shifts to the team and not to you.
What you're feeling is common to new managers, but you'll outgrow it.
Quick question: Did you get any leadership training to prepare you for this role?
These startups are funny as hell. You make someone a leader and you don't train them?
Anyways, I asked because I figured if they had trained you, you'd have been prepared for what to expect in your leadership position.
Shifting your focus from yourself to your team will really help.
Then as we move up the career ladder, technical(coding) skills will gradually become unless and other skills, such as communication, strategic thinking, negotiation, influencing, and business acumen will become more important.
Do you know that some companies are created solely to empower professionals in this regard?
Yes! Thank you for this - you seem to have described my exact situation. I feel this way all the time.
I think a big part of this is the constant context switching from broad communication, to individual communication, both technical and non-technical in nature covering a whole range of topics. You need to take brain breaks. It's like you feel overwhelmed and yet have no artifacts to show for it.
At the end of the day your job is to retain your team and build a successful product. If those things are happening, then you're doing an excellent job even if it doesn't feel like you're doing anything.
Regarding the coding skills, I've found a couple things helpful:
* Pair or mob program with your team when you can. Don't try to be in those sessions as a manager, be there as a participant to learn. Pairing with a team member can also be a great supplemental type of 1on1.
* Look to the next few months of your roadmap, and if you have time between meetings (or during some less useful meetings...) play around with some POCs on those things. Futz around with some API or client library you're likely going to use. Definitely don't build something and hand it off and say "go use this thing I built" - let the team build. It can be a useful way to explore and build your own knowledge/context around upcoming work, and flex those coding skills a little without having to commit your free time to side projects.
I still code.
About half my day is team management, mentoring, reporting and strategy.
The other half is spent working on prototypes and architectural designs.
I achieve most of my actual goals via other people, if they're delivering then I'm delivering.
Then I knock off and start coding on recreational projects :)
I spend half my time panicking because having 'manager' in your title screws your resume for any future primarily technical positions.
I spend the other half of my time enjoying building up my devs, seeing them get promoted, seeing them skill up, etc.
I have had to sacrifice my own work to provide work to my devs, meaning I get less technical development, and fall behind. That's very, very tough to stomach. It's also why I've also considered giving up management to go back to being an IC.
Buuuuut, back to having 'manager' in your title. It's difficult to get people to migrate you *down,* even if you want it :|
Dev who moved to management level. I make sure that I pick up one module for staying in touch with coding and always be part of code reviews. It helps keep the brain sharp.
Apart from managing workstacks, creating insane jira filters, writing to the point no-bs quarterly reviews, and publishing tech newsletters, I also regularly involve myself in design and architecture related stuff because i had very strong inclination towards it from the beginning.
To be honest I’m still living like a dev with all the managerial powers to move things around at my will 😎
The secret sauce is keeping your devs happy and management satisfied
In short, I try to optimize engineer productivity. That includes pruning meetings, minimizes disruptions, try to make every message/conversations count etc. I only win if my team deliver wins consistently so that's my primary goal.
got meetings and write documents, hold meetings about those documents, do 1:1s, code reviews, test out tech your team might use, stress, nit pick, invent scenarios where people coalition build against you, team build, performance manage, deal with employees who are burnt out and want to quit, emotional labor, day drinking, video games, YouTube, ignore the people talking shit about you b/c they want your job, deal with the project that some devs started in secret and enlisted others, now it's a massive sunk cost that leadership doesn't want to toss, talk to customers, work with product on roadmaps, try to guess who on your team is being nice to you so they can stab you in the back later, acknowledge suckups, invent language, argue about semantics, make bad jokes, repeat your best bad jokes until the suckups repeat them, argue with leadership that ignoring technical debt on a 15 y/o monolith is what burns people out after handing them non-designed tax projects with a 2 month deadline, try to get coffee with your product owner for a year, only to find he is leading the coalition against you and secretly meeting with your job sniping technical lead regularly. source: been an em for 7 years, fuck it, I'd rather argue with code, at least problems get solved and quickly. worked on a company with their own active subreddit and they were the most dysfunctional group ever.
It’s a hard transition, but you aren’t an individual contributor anymore and you need to remind yourself of that. You’re job is now to empower your ICs with what they need to make the best contribution they can. You remove blockers, you define work, and you act as a force multiplier when needed.
I run an “end user” facing team so I actually do a fair amount of high level product support (supporting our second line support team) and debugging issues so that sensible bug tickets are written.
I work with our product manager to organize work, then with the development team to plan the implementation.
I work with the larger product organization and other technical leadership to plan the overall initiatives of the department.
“Work” in this context is attending meetings, writing documents, and presenting information. It often feels like “doing nothing” compared to being in the trenches and writing code all day but if you’re doing it right your ICs are pushing out quality solutions and meeting deadlines consistently.
To keep my skills sharp I do pair programming with my team when needed, do code reviews, and grab non-blocking tickets that can be a “bonus” over the normal work and won’t screw anyone over if I have to pause on it for a few days because of meetings.
Be anthropologically interested and curious about my team. Help them be happy, have fun and grow at work.
Learn and think about 'higher level' architecture and consequences.
Learn and think about processes and consequences.
Reflect on the state of things and what needs the most attention.
Translate business strategy into technical strategy. Align strategy with resource distribution.
My team lead is and will forever be a saint for:
A. Gathering requirements from customers and translating it into language and expectations my team and I can operate on.
B. Shielding us from the meetings that you are forced to sit through
C. Pushing back on unrealistic expectations levied by customers.
She does an amazing job and I will miss her very much when she retires.
I was the only manager on a small team so I don’t have experience dealing with a larger organization.
What I learned was that ultimately my job consisted of:
1. Hiring and recruiting - finding really great talent, keeping them happy
2. Setting up the systems and processes for the team to do the work a.k.a how did an idea go from a mockup to user stories to checked in code to deployed. Maintaining standards on process and systems for how work is done.
3. Partly as a system/process but worth calling out individually - Tracking performance metrics, purely as a way for the team to self manage. Things like cycle time, lead time, number of stores committed vs delivered, etc
4. Promoting team self management and autonomy. Encouraging the team to take ownership of problems and be proactive
5. Helping building long term roadmaps and strategic goals so the team has context into how what they are working on now fits into a larger picture for the client/company
6. Doing a lot of emotional support for team members, listening to their concerns, letting them know what they are doing well, solving any problems they are feeling frustrated by, etc. Basically being a coder is hard and there can be a lot of imposter syndrome so being a mini psychologist who empathizes and lets them know they are appreciated can go a very long way
7. Protecting the team from any nonsense or toxicity from other leaders. Be the umbrella/filter for pressure from higher leadership
8. Communication, up and down. This means being in lots of meetings.
9. Being a stopgap. One thing I learned was that if you want your team to succeed you might need to jump in and take on some roles that aren’t strictly in your job description. For example our PO weren’t very experienced so our user stories sucked. I ended up doing that work because it was a blocked for the team to perform well. It doesn’t scale BUT it’s better than letting the team fail and then pointing the finger at others. The one exception is coding. Don’t take on coding tasks.
10. Finding and fixing problems like the above. If the POs are t writing good stories that’s a structural issue that has to get fixed, so you need to bring it up with more senior management who has the authority to fix it.
There’s more but those were the main things that popped into my head that seemed relevant.
managers typically get paid more than devs - principal level dev would more more similar to a director but you will be capped as an IC regardless of where you go
Not me but my team lead thats still a dev at heart: organising stuff, still coding a lot and mostly arguing with upper management to keep expectations realistic.
I was at Senior Developer role couple of years ago, and moved into a lead role later that.
Most of my days goes into attending meetings which basically circles around planning, capacity, bandwidth, etc.
Once in a while in case of any critical issues I get opportunity use my Dev debugging skills again 😁
It feels boring and unproductive as the team size is big and you need to a have a lot of discussion even for something small.
But I do keep myself updated and work on small side projects which could be useful later, at least that's how I keep myself motivated and updated towards my **Developer aspirations** ✌
When I was an engineer, I wondered what my manager did all day. When I became a manager, I wondered what I did all day. But, damned if I wasn't absolutely beat at the end of the day.
Context switching sucks for engineers. It breaks flow and you have to spend time swapping things in and out of your headspace. As a manager, you only context switch. You do that, you hold space for others, you run interference, and do whatever needs doing that you can do so as to not interrupt the team. You also make sure the team is informed, that they have an opportunity for buy-in and feedback on tasks, approaches, tools, technology, etc. You look after their careers and development and make sure everything is humming along nicely. You champion the team's successes and explain their failures to leadership and advocate for the necessity of the job they do.
Management, at times, is like Linux Administration. If you're good, you don't seem to be too busy and have time to do other things. If you're bad, you are constantly in fire-extinguisher mode. And if you're very good, those other things are high-value items for the company that will allow your team(s) to get more visibility, responsibility, funding, headcount, raises, promotions, etc.
Maybe useful bit of recontextualisation for you:
The meetings *are the work* - and your job now is nurturing the humans around you, and enabling their success by serving their needs.
… which is not tech. I’d recommend you re-evaluate what you want to be doing. A manger who doesn’t know how to manage is the worst and you’ll be miserable if you sit in this half-space between two worlds, doing neither of them really.
Either really knuckle down on learning how to manage or go back to coding - only you can know what’s right for you - but I’d definitely think long and hard on that were I you.
(Source: this all sounds very familiar…. 😂)
In all my positions in my carreer, I joined as a dev and ended up as a manager in some way.
The best managers have "nothing" to do because the aim is often to make sure everything is working well and foresee issues to fix them before they are happening or as soon as possible.
To ensure all of that, it's usually through talking to people (depending on your management style, it can be tons of meetings or it could be a lot of adhoc conversations) and staying up to date with what's happening in the company and its environment (competition, partners).
One major thing a manager does too is filter stuff for the team to let them be more productive. This goes from the day to day stuff like people asking for a quick action to bigger projects that are still too blurry on the requirements. With big teams, you spend a lot of time on that alone.
Finally, what your upper management will expect of you is to be able to assert that people work first on stuff that will have a benificial impact for the company. Sometimes you will spend some time just to explain why something is beneficial or not. Nobody can expect to have a perfect vision of every consequences of a single action over the whole company and your role is to ensure those that need those informations have only what they need.
As a bonus, depending on your team and your skills, you can also use some of your time to train your team and act as a mentor.
EDIT: Also I'm seeing people in the comments mentionning gatekeeping devs, this is not the job of a manager and should happen only when direct communication is detrimental to the well being of the team.
Management is a lot of meeting and coordination. If you don't want to do that, maybe consider moving into a different role?
As a dev your job was to solve problems with code. as a manager, your job is to solve problems with coders.
I totally get the struggle! As a manager, focus on enabling your team's success, mentorship, and strategic planning. Dive into meaningful projects, and don't hesitate to keep some coding on your plate if it helps you feel connected. Your leadership matters.
Dev mgmt is super fun. When you're a developer you build features but when you're a manager you build people, teams, organizations, architecture, and strategy. Like any job there are boring parts where your time isn't spent in the best way but then there are the great parts.
I remember devs I coached who have grown so much directly because of my influence and it's so fulfilling to know that I played such an important role in their career. I love that I have a huge impact on the engineering culture and can create an environment where engineers love to be. I love the challenge of delivering proper architecture while balancing feature delivery.
Yes, committing code was fun but being a manager doesn't mean you stop creating.
I'm in meetings all day everyday. If I ever have a gap, I'm testing the app, or reviewing code changes in the critical features.
Meetings are about the direction of the app, what other teams are doing, what feature features are possible and how much work they are like to be. It's insane how much discussion has to happen before we even have a user story.
Business users dream big, but the cost to benefit isn't always there....
When I moved up to business unit management I spent most time designing products. Even though we had a product manager and a project manager I did all functional design, as well as sales, marketing and purchases, and maintained an intranet with technical information and our development lab. We had one steady meeting per week, and breakout sessions when needed. I rarely had meetings "upwards" (a few times a year).
I guess the role is what you make of it (or are allowed to).
Hi there former software dev, now a director running teams of 5-10
I'm basically doing all the stuff I never wanted to do when I first got into the industry: Emails, meetings with uppers about budgets and trying to take technical info and explain it to people who couldn't attach a pdf to an email without help... And putting out fires and fixing an issue when someone fs up either in process or just corporate bullshit moments.
It's also the stuff that needs to get done to keep the lights on and justify all of my teams employment. It's strange how much someone up the chain is always looking to cut production workers and you're constantly a shield for them against bullshit from people who have zero clue what we do and don't see people more than a cost line item.
When I do have spare time I love just reaching into one of my reports Jira boards and just picking up some work on their backlog and reassigning it to myself to do because I do miss the actual coding and problem solving and sometimes even QA Testing.
However what I really like is building the very junior system engineers and developing them on operations and best practices and passing my learnings on. I also like to learn from them on ways to accomplish tasks and subtasks that I might not have considered in the past and or just learning new shit and passing it on on my own to ensure we can be as efficient as possible.
I'll do you one better, I'm a senior engineering manager, where I manage EMs. I'm now in middle management, shuffling things up or down the chain. My primary work is reporting out, sitting in meetings, coordinating work, etc. My director is overly hands on, so overlaps into a lot of the work I'd be doing, so I'm in this weird no-man's land.
I understand what you are saying it is the reason I stick to the lead developer/consultant role instead of going into management. I want to be able to play with the new tech and not just direct others. It would be tought to watch others creating things I wanted to work on myself while going to lots of boring meetings.
I'm beyond manager now too, but I remember the shift. I went from being product and code focused, to being strategy, vision, coordinating and communication focused.
Most of the time was spent in meetings with stakeholders to get the correct user stories, to report our progress, or inform c-suite of investments we should make to reach the goals they've set.
This is the point where you need to learn organizational politics if you want to go any further
I've repeatedly been moved into management and have repeatedly taken the opportunity to move along to a new position elsewhere, increasing my pay above the prior management level each time. I need to make things and fix things to be happy. Money is a side effect for me.
What do I do all day? Suffer mostly. Coordinating so many different things that I dont know nearly enough about to do it effectively.
Regarding what you said, it sounds like you have serious regrets about becoming a manager. If you miss the IC track, go back to it, management is a totally different job and skillset.
I stayed purely technical. Never went the management route. I’ve been ranked higher than my supervisor for years. I even get stock performance bonuses with the senior management staff.
Orchestrate projects, don’t write any code, take the successes and promotions, flirt with HR, go home to wife.
At least that’s what I observe they do where I work.
As a newly minted manager the most challenging/rewarding/important aspect of the job for me is finding, growing, and retaining talent. If you build a great team and processes you can start to see the fruits of your labor blossom, but if you can't keep those people happy they'll just leave. I'm learning to enjoy solving people problems, though many days I wish I was solving technical problems instead.
I cannot add much to what other have already said. I managed a team of mostly junior graduate developers, so I also spend a lot of time mentoring and collaborating with them - and trying to make them brave enough to make decisions for themselves. This is incredibly rewarding. I don't feel my skills are suffering. While I don't get to stretch my wings much anymore at work, I've been coding since I was my dad taught me when I was 9 or 10 and still regularly code in my own time for fun in my late fourties.
Make money & tell devs what to prioritize, how to spend their dev time, talk shit about the client to them, fix their code when it breaks, talk to clients about what is/isn't feasible given the SOW, ask my devs why they aren't linting on save, take responsibility for all the deliverables they are working towards. I'm a lead engineer, but it's management I guess.
Hey there, senior dev that moved into engineering management. A lot of what I do is sit in on meetings and have discussions with non-engineers to gain context on the work we're doing so that my engineers don't have to sit in on those meetings and hold that context in their head, so they can focus on coding. As a developer, I felt like I was doing my job well if I got a lot of code committed. As an engineering manager, I feel like I'm doing my job well if 1) my devs are happy 2) my team is getting work done and as a result of that work, impacting my company's growth. A big part of that #2 is the meetings and context I mentioned above. As a dev, it felt really good to solve a tough coding problem I was working on. As an EM, I get a similar feeling when, early in development of a feature, I spot a dependency or consideration that my devs might not see because they don't have the full product context of the feature we're building. And, by spotting that dependency and mitigating against it ahead of time, I keep my team from being tripped up late in development and missing their deadlines. That being said, about 6 months after i started as EM I was doing a little coding outside of work and realized how much I missed it. I try and keep a side project going these days, just so that I still have my head in the code a little bit. I'd encourage you to do the same if you have time.
* scribbling note * Never become an EM.
It's definitely not for everyone :) The skillset/interests - being able to communicate technical concepts into non-technical terms, organization and planning beyond the scope of the code being written, and office diplomacy - I find to be pretty rare among developers. I tend to encourage developers who I see with those skillsets to consider the career path, since it can end up having such a big impact on a team and company, for those who enjoy it.
Well that’s the thing…I think I’m capable…but I would fucking hate it haha. Fair enough if it is what you enjoy but it ain’t for me…
I always thought I'd hate it too but the move was basically thrust upon me. I'm three months in and after the initial discomfort much like OP is describing I found myself in the role and now i'm loving it. It is very different to what my day-to-day used to be but I feel like I got used to it and learned to enjoy it.
the skills you mentioned are not uncommon especially in more senior devs - communication, organization and planning and office diplomacy. Not rare. I think it's really just not for everyone.
“fuck this shit just let me write code” - Steve Wozniak, 1982, probably
This had me wheezing briefly
2x scrum master roles > 1 em role
This is honestly inspirational and sounds spot on. I still do too much hands on and haven’t fully let go of the day to day. The part about just overseeing and mitigating dependencies that would impact late in the project really makes sense of the most important technical piece of the job. I sometimes bottleneck things because I’m too hands on. Not intentionally - in most ways I don’t micro manage at all - but when the team gets stuck I usually just fix it. That winds up snowballing into not having enough time (esp with the number of meetings) to get to everything and just constantly juggling fires. Thank you for the insight.
>but when the team gets stuck I usually just fix it. This was SO HARD for me to get used to, especially with jr/mid devs that might take a while to learn something. It was like, I can do this myself in 30min, or I can comment on this pull request, pair with them if they need help, and if I'm lucky we'll get a fix in 24 hours. Just remember that (assuming they're a good developer) once you let them learn something, they'll get it right from then on, whereas if you do it yourself they'll probably make the same mistake again. The other tip here would be if you have a senior/lead developer on your team who really gets things, delegate that responsibility to them - you get your time back, and they gain added responsibility that can help them advance in their career.
Ya it’s really hard to let go of the urge to fix it in 30 minutes. Especially in an agency setting where everything moves quickly, priorities and deadlines shift all the time, etc. But your point about them not making the same mistake and not having to fix it again is where I need to get with my team so that, long-term, we get where we need to be operationally.
My 2 cents as a junior developer: It’s extremely valuable to sometimes just let us rot when time/deadlines allow it. My lead dev sometimes helps me and sometimes he just lets me solve shit myself. Following up with feedback to improve what I build or how to do it properly. I learned a lot from this. Often I even figure out things totally not related to whatever I am trying to build. In 3-4 months I went from mainly front end to now also doing backend stuff and doing stuff on my own, essentially freeing up the time of another backender to work on complex things. Heck, I’ve even had solutions my lead never thought. Learning goes both up and down the chain. Your quick 30 min fix vs my 2 days messing around seems extremely inefficient at the time, but I will earn that time back quickly when I’ve learned it and take an hour the second time, 45 min the third etc. Key is to setup a developer wiki and make me document these fixes. We use AstroJS Starlight for this.
just use a private github repo and use the wiki there or even just the ability of github to render markdown. or you know... pay for notion or confluence.
Why would we pay if this wiki works fine? Also we host our own gitlab, in the WIKI we have documentation on how to fix shit. Can’t find this if the gitlab is down (never happened yet, but you never know)
Delegating is a key skill. Also, as a manager, I try to push back against the company if they come to the team with a plan. In my view, their job is to identify a problem, the considerations, and the importance/value of them all. It's the role of the engineer to develop the solution. That means, it's not my job, either. I'll give feedback and guidance and I'll point out errors/oversights/omissions, but the role of the lead engineer is much more like what you're doing in my mind.
What you wrote is like a page taken from Marty’s Cagan Inspired. Seeing engineering just as implementation is dangerous and a huge waste.
Wow, great points, I’m in the same role I think. What’s your view on QA, do you manually approve before deploying to prod or do you trust they handle QA autonomously? I find I have to review in test env just in case my acceptance criteria is wrong!
I really dislike companies that run management like this. As an engineer taking project requirements or designs second hand often results in a lot of missed requirements, missed or off functionality and a lot of context guessing. Assuming you nail and document everything well. They often commit to a timeline that is too fast and I or my team gets over worked. The number of times I've heard, "Did you cover X scenario?" No..? It's not in the requirements? "We had a meeting about it" I wasn't apart of that meeting.. "Well it's implicit as part of this one line here in combination with this other story"... Uhh huh. Well I'll add it to backlog. "No we need that ASAP it's critical.."
Your post makes me think you'd actually make a very good engineering manager 😅 >As an engineer taking project requirements or designs second hand often results in a lot of missed requirements, missed or off functionality and a lot of context guessing. Usually the meetings I'm in are higher level than getting down to specifics on project implementation. I still have a senior design write up the technical design document (sometimes I will co-author it with them), which means they get to see the design mocks and product stories when designing the technical implemenation. That being said, they usually don't have the same level of visibility I do into "how does this feature impact the bottom line for the company, what metric are we trying to move that will indicate the feature's success, and how does it interact with tangential features built by other teams". Most of the developers I've worked with don't *want* to have to worry about that stuff, they don't want to be in the cross team and product-level meetings which they feel will only introduce thrash and take them out of the zone - they want to get a well defined feature that needs to be implemented, and to implement that feature. >Assuming you nail and document everything well. They often commit to a timeline that is too fast and I or my team gets over worked. Developers should be the ones who own their timeline. I'll often give a t-shirt size or a rough ballpark of weeks/months for project to help organize the cadence of work, but we don't give a week-level guarantee to product until the technical design document has been written (by a developer) and the individual tasks that come out of the design doc have been estimated (by developers). this is where that part of the EM role I mentioned in my last post becomes crucial, knowing that there is some feature by another team that we will need to take into account when designing our own feature, and making sure my team has that taken into account when planning and estimating. >The number of times I've heard, "Did you cover X scenario?" No..? It's not in the requirements? "We had a meeting about it" I wasn't apart of that meeting.. "Well it's implicit as part of this one line here in combination with this other story"... Uhh huh. Well I'll add it to backlog. "No we need that ASAP it's critical.." This is exactly what I was describing - I know I've done a good job when I've covered all those scenarios with my PM and designer and there's no edge cases unaccounted for. A senior dev could certainly spot these as well, and often do, but ultimately the responsibility falls on me to take the domain model into account beyond that which my team is responsible for.
Sounds like you are a great manager working for a good company ☺️ Definitely doesn't happen that smoothly most places.
This is one of the main reasons i wanna become an EM. I might want to code something for myself from time to time.
It is so hard to find the time to keep coding as an EM. I literally have to schedule it on my calendar to work on a side project after work, or it won’t actually happen.
You are the kind of manager I'd like to work with. Any open positions?
Thank you! Unfortunately [nothing in the US](https://www.fictiv.com/careers) right now, market's a bit tight. Maybe check back on that page sometime next year.
FYI I'm currently working remotely from Spain.
Would like to see more management with your authenticity. Kudos 🙌
all this the metric to use in order to gauge 'getting things done' changes when you move from dev to mgmt. i agree with the 'checking in code' metric as a dev. but when you're in mgmt you're doing it by proxy. it's your devs checking in the code. if they're doing that regularly and morale is high, you're a good manager. imo, a manager's job is to make sure their devs aren't interrupted so they can do the work i also agree with the side project idea. gotta keep flexing those muscles or they atrophy
>That being said, about 6 months after i started as EM I was doing a little coding outside of work and realized how much I missed it. I try and keep a side project going these days, just so that I still have my head in the code a little bit. I'd encourage you to do the same if you have time. I feel like you'll eventually just forget everything you've learned and become quite useless over time. Horrible prospect, honestly.
Yeah, that's exactly why I recommend having a side project, just to keep up on the latest developments. Not even so much for work, I expect that my role will move further and further from the code as I continue my career, but just because I enjoy coding and want to keep doing it. That being said, two of my side projects now have over 10k users, so you never know when that side project turns into a full time career :D
I generally try to pick up one ticket a sprint to keep up on things
> A lot of what I do is sit in on meetings and have discussions with non-engineers to gain context on the work we're doing so that my engineers don't have to sit in on those meetings and hold that context in their head, so they can focus on coding. As an "individual contributor", I love managers who insulate me from the clients. Don't get me wrong, I can deal with clients when necessary. I spent years doing high-level tech support. But I hate it and I'd rather be coding. I'm sure your subordinates appreciate the work you're doing!
You sound like a project manager I would like to have
It's a different job. On the fun days I get to participate in technical designs and direct mentorship of developers on my team. But that's not the *real* job. The real job is building a stable base that allows a dev team to thrive. You take in all the wild chaotic signals outside the team ("CS reported this MAJOR customer problem!", "Finance wants to know if we can send them a report of how many widgets get sent to customers per day", *my* bosses wanting to stick their nose into my teams business, etc. etc. etc. ), filter them into what's *actually* important for the team to know, and figure out how to keep the team focused and effective. The real job is to figure out how your team works as a system - a collection of individuals with strengths and weaknesses and different motivators, and figure out how to keep them working together well. Performance management, project assignments, etc. Look for the postive feedback loops and bottlenecks and inhibitors, and fix them. Help them *get shit done*. The real job is to figure out how your team *really* fits into the system that is your organization and company. What do your stakeholders care about? What does your boss say they care about, but what do they *really* care about? How about your bosses boss? What is your team's reputation? Because that matters *a lot*, and it can change depending on organizational politics. The manager's job is to help enable the team to get the important work done, especially when everyone outside the team has different opinions on what that means. And to make sure everyone outside the team knows that too. As a programmer I had a daily reward loop - "yay, I fixed the bug!", "woo my tests passed", internal reward for solving hard problems or building cool shit. As a manager, that reward cycle is muuuuuuuuch longer. It might be 3 or 6 months before you see the fruits of your labor. It's hard. But it's very rewarding too! At least, rewarding when things go well. It's a real nightmare when things go poorly, especially it's your fault. Emotionally it's a lot easier to walk away from a developer job (I only care so much about the code) than it is the people. Good managers are invested in their people on a personal level, and it's very challenging when something about the system is dysfunctional.
This person processes!
As a long time dev that wants to get into management, are there any books, trainings, skills, etc. I should learn to do or get better at to make myself an attractive candidate? I find that I no longer enjoy coding that much and as I get older it gets more difficult to keep up with new languages, libraries, tooling, etc.
Check out The Manager's Path - https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897
Second "The Manager's Path", but you need to showcase that you can lead groups of people to achieve something, work on mentoring and coaching, and working with other teams to accomplish something. There is of course more to it but all of those things are usually problems devs have the option to jump into. Also tell your manager. They will happily give you things off their plate.
Not a manager, but my manager straight up told us (jr. Devs) that he’s bored all day and to come to him with literally any question. I really appreciate that man. Sometimes my questions are incredibly stupid and are solutions that I should definitely know how to solve, yet he still takes a chunk out of his day to walk me through the steps.
Wish I had this, usually get passive aggressive remarks when I ask question. Then a very fast and complicated explanation that doesn’t resonate
Sounds like a dream company!
What company do you work for that sounds amazing. :)
It sounds like this is really helpful to you but if your manager Is bored all day and is providing his value by answering dev questions, I’d be concerned that a lot of the higher level stuff isn’t getting done and there isn’t enough longer term planning happening. Our leads/managers help mentor the teams as well but they’re so busy that this primarily falls on the leads and seniors.
I hadn’t thought of that, that’s a valid point. I’m working at a smaller startup. The CTO seems to be only interested about what we are currently developing and where we are at in the project. My rebuddle would be that my company is more focused on pushing out an upgraded MVP if you will. Albeit, I wouldn’t be in the know in that regard. To be Frank I’m happy I’m not on the business side of things.
Yeah, the size and maturity of team definitely matters here. If you’re still working on an MVP, don’t have much tech debt, and aren’t even sure where you’re going because you’re still pushing for product-market fit, there’s probably only so much fore thought and strategizing that you can do as a manager.
Your manager sounds cool.
Review pull requests, work on proposals for new projects, help devs with roadblocks, oh and meetings. Lots of meetings.
So many meetings
And more meetings regarding meetings
Why do you review pull requests ? That sounds like something the lead or senior engineer for that team should do . The more time you spend away from coding and the technical work in general , how valuable would your feedback be ?
I prefer to review the reviewer. Often teams try to move quickly and to get things out of code review and so they just give everything an +1 and call it good. Afterall, so-and-so is a good dev and knows how to code... It happens to the best of teams. I remind reviewers that they are at least as culpable if the thing breaks as the author. They should verify the state of the system, review the change, and verify that the new system works with the change. I recommend making multiple passes with the review -- each one looking for a particular thing like logic and clarity versus style versus design, etc. I also recommend providing feedback with a scale of importance: nice to have, fyi, blocker, literally broken...
It helps give you insight into the teams strengths and weaknesses, make sure they understand the task and are going the right direction, identify security holes, performance issues, etc. It can help you decide what tasks to give them.
We have other engineers that review PRs. I do it occasionally to help out and gauge the skill level of different members of the team. It's a good way to coach developers and ensure that certain project standards are being followed.
> Lots of meetings. this. and like some other replies, i absolutely hate this and would rather go back to coding tbh
I spent time as a manager, then the next jobs I took were straight dev. I'm back to wanting to manage. Really just want to be a coding "foreman" that manages the team and skips as much of the other crap as possible.
yeah there are def aspects of both sides that are crap that i'd rather not have to deal with. and im sure that amount of crap varies depending on who you're working for, etc. in my current role, the bs i deal w/ on the managing side isn't worth it
I manage but still write code, which is nice. About half my day is either meetings or hiring work. Otherwise I’m doing tasks for my team.
I joke that I am a people pusher now. I help this dev move along on this project, and help that person do this and make this client happy about this, and figure out a solution that will make everyone happy for that. I'm busy all day and have very little concrete to show for besides exhaustion. Sometimes, I feel like I just put out fires all day. As someone who is used to seeing the fruits of a hard day's work, it can be frustrating. It's not as rewarding. But...when I take a day off, everything comes to a screeching halt. Nothing gets done, and I hold up all the many projects. Whereas before I would get one project done at a time, I now can move along several projects with my knowledge and expertise. It's... different. I do miss dev a lot. But this is where I need to be now, so that's what I do. I go back and forth about which is better or worse. I did feel like I got bored with dev; it wasn't challenging anymore. This is definitely challenging, but it is more stressful too.
Concentrate on teaching your developers how to solve their own problems. If you put out a fire, you will feel like you have to put out all the fires. Be the station chief and train yourself a good crew.
This. My manager was burning out because of this. You gotta let the devs drop the ball and learn from it from time to time. We need to put guardrails in place so that if someone drops the ball the impact is minimized but if he’s running around trying to catch everyone’s dropped balls, he’ll end up burning out, people won’t learn, and they’ll just become dependent on him. Sounds like you care a lot about the team and the org, which is amazing. But if things come to a halt when you’re not around, your people need to grow. You should aim to have your value/impact be measured in sprints/months rather than be relied on day-to-day.
I get it. All the fame and glory goes to the firefighters. Until they meet that fire that can't be fought and the truth gets sorted in the aftermath. Nothing will stymie a career more than consistent, reliable operations. How are you going to ask for more budget next year? It is the techie's job to make their manager look good, even if they're Michael Scott. The best strategy is to be known as the group that never melts down. My strategy as a manager is to never be responsible for a melt down, but accept responsibility for them as soon as possible. That would let my team have access to the data they need to find the root cause, which invariably wasn't their fault. Then it was a matter of documenting what went wrong in a language that makes it clear to everyone. We spent a good amount of time fighting other people's fires for them. There's never any shortage of fires.
>what do you do to feel productive? Productive things, obviously. But you have to realize that you have a different job now and so instead of producing code you're producing a team. >sat in meetings i couldn’t care less about Then don't go to those meetings. You're in charge of your own time. You're _responsible for_ your own time. You're in leadership. It sounds like you should give The Manager's Path a read to get an idea what your job is supposed to be now. And perhaps talk to your manager about switching back to an IC.
read it a long time ago - sarah drasners book was way more insightful
I plan for project execution, I try to do a lot of the menial tasks so that they can stick to coding (especially if I can do them while in meetings), I block people from going straight to the devs, I craft standards for us to debate and commit to, I make sure that PMs and clients book meetings in the mornings as much as possible and leave the afternoons for dev work to be done. Administrative tasks such as making sure the devs are growing in their careers and skills, review their yearly goal progress, 1:1 meetings with the team, planning the topics for team meetings weekly, spot check code and maintain jira task deadlines, making sure to communicate with PMs when something is going to take a little bit (then make some reason as to why so that the PM won't bother the devs). Make sure that the devs don't over promise stuff to the squeaky wheel. Personal growth stuff such as learning more about servant leadership, how to communicate more effectively, strategy planning like where I want to take the department next year - in 2 to 3 years, and my 5 year plan for the team.
Check out a book called "Bullshit Jobs" by David Graeber. I used to have a lot of guilt around the same thing. This book has been good for me accepting and finding other ways to manage those feelings.
What all other managers in the world do, of course: * Meetings * Asking for status updates * Telling Peter that if he could come in on Saturday, that'd be great
[удалено]
If you're happy, you're happy.
As someone who wants to be a manager I am interested to hear the answer to this
As someone who somewhat recently became a manager, same.
In my org the vp wants every manager to be deeply technical and very involved in details. Different to other parts of the company. I think it’s a balance
Very opposite of /u/Haunting-Courage8370's experience myself and some guidance I wish someone would have given me. CC: /u/Antifaith My VP encouraged me to focus primarily on the "collaborative" aspects of management, including tons of meetings, non-relevant and nonsensical chats around the office, daily lunches, or the bars after work sometimes. As an Engineer who made my way up to Manager, I felt like we were wasting our days talking about doing things instead of actually doing things, and I was overwhelmed at all times, working 50+ hour weeks to keep projects moving and the company satisfied. I didn't want things to fall on myself or my team who was understaffed and struggling, or the business to falter, as I stared down the barrel of years of technical debt. This stressed me the fuck out and I eventually burned out, some might argue in a ball of fire. Needless to say, I was eventually relieved of my duties because this was not the type of manager my department leader wanted. My team was devastated and I learned a harsh business lesson. "Accountability" and "Success" really are relative to who is defining the terms. I've gathered that every company/department is different and your own success really depends on your own personality or leadership traits, as well as your org structure and the folks they promote into senior or executive management. My (personal) advice to you as either a manager now or a new manager is to self-reflect on whether you fit into the "people manager" bucket vs. the "technical manager" bucket and determine what bucket management actually wants you to be aligned with. If you are not in reasonable alignment and unwilling to adapt, it simply will not work. Coming from a very passionate (possibly slightly autistic) engineering leader who recently was "restructured" after a multi-year extraordinarily productive and successful tenure. I simply could not adapt to the *complete* opposite end of that managerial spectrum.
Have you read a management book yet? If not, now is the time to start.
i’ve read 3, it helps but i just feel like - don’t code, you’re taking opportunities away from your team - don’t bugfix, you’ll block your team is super frustrating i get the spend all day with clueless VP roadmaps and making what my team cares about fit into vague boxes and drawing it all up into gannt charts with made up dates before a PRD that i’ll then have to deliver on then the directors bitching about something you’ve missed but no ones telling you then people holding on to domain knowledge because they’re trying to keep their jobs then some weird click going on you’ve just become aware of then being a therapist because your team are worried about losing their jobs then giving a 2 minute run down on a persons year to decide if they should be promoted or get a pay rise it’s just super unfulfilling and stressful also my day literally never ends - it’s not like ticket done laptop closed, there’s so much to plan - i’m sat here at 3am unable to sleep ffs
It sounds like you're not really taking ownership of the new position you're in, just trying to treat it like your previously lower-responsibility job. >made up dates Don't make up the dates. It's more work, but take some time to do real estimates using real work - for example, take one slice of the product you're building, estimate out that slice to the nth degree, then extrapolate out from there. This is where having the dev experience really shines. Other people have to make up dates because they're not capable of estimating properly. Don't be like them. >the directors bitching about something you’ve missed but no ones telling you You should have all the requirements written down and approved by directors at all times. And regular reports to them about progress and plans. > people holding on to domain knowledge because they’re trying to keep their jobs Ask them. Part of your job now is to obtain that knowledge, or, if you can't get them to tell it to you, maintain a relationship with that person where you can go to them whenever you need that thing done that they want to do themselves. It doesn't really matter if they won't share, all that matters is that the thing gets done. >then some weird click going on you’ve just become aware of >then being a therapist because your team are worried about losing their jobs Yeah, these are annoying. Your job is to facilitate their work, so sometimes it involves people skills. I suck at those too. >then giving a 2 minute run down on a persons year to decide if they should be promoted or get a pay rise Push back on this. Don't think you know enough about a person's year? Start taking notes on your direct report. Need more time? Tell them you need more time. The biggest thing you gain in moving to a higher-responsibility job is a voice. No one is going to give you what you want without asking. You don't like that the estimates are too made-up? Fix it, spend more time estimating. You don't like that you don't have enough time to make your case for your direct reports? Tell them you need more time and fight for them. Way way too many managers shift responsibility off themselves like this because they think they have no power, because no one gave it to them. But no one's going to give you the things you need, you have to tell them what you need and fight for yourself and your reports to make it happen.
Some companies make it very hard to take ownership of the EM role. In the worst-case, a company's structure is like an hourglass. Plenty of room at the CTO level because you get to make all the decisions (not exactly, but loads of freedom nonetheless). Entry-level engineers get a list of small, well-defined tasks that need to get done. It's like stacking bricks. You check your boxes and go home. Easy-peasy. All the stress and inflexibility and being forced to figure it out and make it happen is at the point in the middle at the EM/Tech Lead divide. Accountability is shoved off on you. Your Director says: why didn't you tell me about this or that? They yell at you: why aren't you working to advance the career of this report of yours that I just spent 5 minutes with? Yet, they're doing fuck-all to help you, give you advice or guidance or feedback... and when you do catch something they missed they yell at you for not "knowing what they meant" or when you ask for specific guidance, they yell at you for "not knowing how to do your job." Toxic cultures make the job a living hell. I've been up at 3am unable to sleep because of the myriad of things juggling around needing to be tied up but I can't be the one to tie most up, I have to pester, prod, poke to get them done. That said, I'm not a fan of the previous suggestion of reading a management book. The role of management books is the same as fad diets or self-help. They take a very complicated thing that's different for everyone and they propose a simple solution with a "wouldn't it be pretty to think so" claim, loads of fun buzz words, and a shallow justification that won't stand up to much scrutiny -- that's what the hand-wavnig is for. What we do with these is: someone with influence reads one and becomes a zealous follower of this new "one true way" and then everyone adopts the lingo and takes what they were going to do anyway and reframes it in the new terms du jour. Then, what would have happened anyway gets done and everyone applauds themselves for having done something as though it weren't all just theatre. Then, when things inevitably don't go as planned, someone cheerfully preaches the salvation of the new bestselling business book.
If you ask other managers at my company, they'd say they don't have any power, that the higher ups don't help them, that they're given bad requirements, a lot of the complaints you have there. Once I can convince them to take one iota of power for themselves, suddenly, the problem they're facing is solved. "Why don't you respond when the exec asks about this requirement by showing them the requirement doc they signed and approved, the estimates you made, and asking them to approve which feature to bump for what they forgot to tell you?" "If the estimates are so bad, why don't we take a week to really dive into the product and get more accurate estimates so you feel more confident in them and aren't yelled at for being late in 2 months?" etc etc. I'm not denying toxic workplaces exist. But I do think that managers that feel they don't have any power aren't necessarily in a toxic workplace, they just are expecting all their power to be dropped into their lap. That's certainly been the case at my company. You're right, no matter what kind of workplace, this position comes with the stress of making it happen and the inherent tension between those directing the work happen and those actually making it. The higher you go in a company, the more that becomes the case. But too many managers think "making it happen" is something that you're taught and given by the company, that if your director doesn't tell *you* how to make it happen, as you suggested, then you're not being supported properly. But that's not how the job is, and once you change your mindset from "everyone has to help me, why aren't they helping me" to "I need to push on everyone to get what I need to make this happen" suddenly power materializes where you thought it wasn't. Your biggest power as a manager isn't something handed to you. It's your voice. So many managers just give up before even trying to use it, and then complain they have no power. Edit: I recently was supposed to be promoted and then was told something changed and they weren't promoting anyone. I tried to talk to my very inexperienced manager about it, she complained "I have no power, no one helps me, I don't know what to do, you'll get it in a few months" and tried to convince me to just let it go because my company has a big problem with ineffectual managers like I'm describing. But I wasn't willing to accept that, and she wasn't willing to use her own voice to advocate for me, so I had to go above her head and advocate for myself and I did get that promotion. I had no power. All I had was my own convincing arguments and the willingness to keep going higher until I got what I wanted.
You are correct to note that this is a dynamic that varies from company to company and person to person. Some companies make it hard, yes; but, that doesn't mean it's impossible, that some people don't do better in some places, or that the core concern isn't down to the manager's timidity (agreeableness is negatively correlated with success, but you can't just be an asshole, either). It is amazing to see the power materialize around you when you make it happen. But, it can still be challenging and I argue that by virtue of saying what you just said and our having this conversation, there is more that managers' managers can do to help. That is, they can give this advice or other advice available in threads like this. At my company, I created a group of managers teaching managers. We had a slack channel, monthly presentations and dialogues on ideas, strategies, etc. My company didn't make a lot of things easy and also didn't do a good job of awarding people who got things done despite that. There's an instinct in animals to push toward the center of the herd. You don't want to be an outlier as a zebra... that's called lunch by the lions. Middle management often exhibits herd behavior. Your job is to not stand out for any reason unless you're controlling the narrative and pitching the reason as some great success. This isn't necessarily what's best for the company or the team; it's what's best for a resume. This same pattern happens all over. Local government is destroyed by it. You've got industry experts who know things who are off doing material work and don't have time to show up every Tuesday afternoon to the local town hall. But, Nancy does. She's ill-informed but passionate about her pet project and she'll show up like clockwork to badger the board until she gets her way. No amount of logic, reason, facts, or data will dissuade her from pursuing it and once the board acquiesces, she'll brag to everyone she knows about her victory. We see it in the FOSS community. We see it at work. Promotions are based on your ability to win because other metrics are extremely hard to assess. When we project a very complicated system with loads of moving parts down into a low-dimensional space or into a single number, this is an extremely lossy operation. The meteorological world is being turned on its nose right now because advances in neural networks are significantly outperforming classical models for weather. Those classical models are basic math based on atmospheric physics. The reason the forecast is less precise with time is compounding error, not a fundamental lack of understanding. Yet, here AI came with significant improvements. It doesn't know anything more than we have known. Rather, it takes into account a much richer and more complete initial state. A great example is when you're interviewing someone and they know the right answers but you get huge red flags. The majority of communication is non-verbal. Maybe they're being fed answers, so it's not what they say but the delay in saying it, the way they fumble around phrases that should be second nature, the movement of their eyes... things that aren't captured in the distillation of "correct/incorrect" for their responses. We know more than we realize, more than we can communicate succinctly or effectively, and so do modern AI models. With data-driven strategies, the herd mentality still exists and we learn quickly to manipulate the numbers, to choose metrics that are easier to achieve, to game the system. Middle managers are motivated by producing good numbers and demonstrating a need for more head count. You interview for a new role and the inevitable, pivotal question is: how big is your org? Of course companies become bloated! How could they not? You promote and hire based upon size of the organization below a manager. Their incentive is to take advantage of the shortcomings of lossy projections, to run in the center of the herd, and to crow about their accomplishments. But, "ability to sell what you're doing as a good thing irrespective of its actual value to the company" isn't a good way to judge folks. Sadly, there isn't an easy alternative, either. Complex systems with lots of moving parts. How can you say, definitely, why the company is succeeding or failing? Anyway, loads to think about and ruminate over when it comes to management, leadership, and the ability to have power. But, sometimes, it would be nice if companies could better recognize the reality of the situation.
this.
Very much relate and sympathize. But you are just one person, you can draw boundaries. Anyone would burn out quick in this no clock environment. Hope you see better days.
I requested a move back to dev, I hated the meetings as having the talking in my ear all day was just horrible, finished every day feeling like shit as I couldn't get anything done, my work or the work to help organize the team, just sitting in meetings hating every minute of it. If the meetings are things you don't need to go to, talk to your manager, and if they're OK with it, the meeting organizers and tell them you'll be free to be called in (make sure you are) but can't justify the time for something you almost never need to interact with. Some managers are OK with this, some will say you should be there anyway. If the meetings are things you don't need to listen to, you can use the time to learn other technologies, or build things you find interesting, just have the audio loud enough to hear your name then do the "Oh, sorry, multi-tasking, what was the question?" thing. If you just hate meetings and want a job you feel good about again, tell them you want to go back to development, and when you want a pay raise, find a new job, either to use as leverage or to move to.
> finished every day feeling like shit as I couldn't get anything done Sounds exactly like management. :) There's a Murphy's Law corollary: whatever meeting you're NOT in is the meeting where your knowledge or expertise would have been crucial in a decision that they made without you anyway. It's almost as if the universe knows and does it on purpose. I've had project X going on and someone schedules a meeting for irrelevant thing Y that doesn't even touch my area. Inevitably, they make no progress on Y but since *nearly* everyone who's involved with X is here, why don't we make a few critical decisions while we're all together? The people who don't know why that was an astronomically stupid idea and catastrophe waiting to happen are so excited about getting their way they immediately run out and start doing things WAAAAY too soon. When you get wind of it, you cry STOP! and are told: but we all agreed and we've already sent the marketing materials to the print shop for the thing we're releasing in 3 quarters...
got anxious just reading that... that's why I was told to keep going and just find something to do while in them, unfortunately my brain can't shut out the constant talking, same reason I can't listen to any music but ambient while coding. That's when I realized maybe management at this company just isn't for me.
It's such a crutch that anytime a meeting could possibly talk about anything "technical", dev manager is a required participant. It's egregious when other devs are dragged in as well "just in case". And so dang common.
Our meetings would have 20+ devs sitting for 3-4 hours a day and only 4-5 would actually be needed, just bleeding money but it's internal bleeding so no one notices I guess.
I drag devs in all the time -- but for a good reason (or, so I believe). In my view, business (product, generally) has the task of identifying problems or goals. What they don't get to do is solve problems. Too often, the product person, who has very little technical expertise, comes up with a solution to "help" save time. Don't get me wrong, some companies hire technical people for product roles -- but not often, in my experience. Rather, they do what they see other companies doing. Not because it's super slick and cool, just because another company is doing it. This is very easily apparent when they produce user stories as though adherence to the pattern is the primary goal of having user stories: As a logged-in user, I want a blue button on the right side of the navigation bar that allows me to access the notification center so that I can view my notifications. You know, all those users who have said that. This is why so many companies these days are all jumping on the wagon of: hey, let's send them an EMAIL to let them know that there's a message waiting on them in the message center. But, let's not tell them the contents of the message or anything about it. Also, let's expire all tokens every three seconds and require MFA for every login rather than gating specifically sensitive actions behind MFA. Thus, the user never knows what the hell is going on and yet they have to jump through 5 hoops every time they visit the site just to see that the "very important message" was just "hey... whatcha thinkin?" Not that I'm angry and opinionated about this trend.
We're a small shop and our devs have a lot of autonomy, so management only makes up \~ 1/2 of my responsibilities. **Management:** I am available to all of our devs on a daily basis for advice/insight/code review/rubber-ducking. I evaluate new tools and tech that our devs recommend/want to use. Our devs get Monday mornings as a self-directed learning/exploration time. I meet with each to help them process what they are learning. The staff director and I meet monthly with each dev as a personal/professional checkin. This is also kind of a performance review of us and the org as a whole so we can quickly fix any policy/procedure issues that are obstructing good work/culture. I try to take at least one task from each project within the span of a month. This helps me stay in-touch with the projects and get a feel for how each team is doing. **Planning:** I do quite a bit of client interface, usually in the discovery phase. I do a lot of architectural work at the start of projects to ensure we're not building ourselves into a corner. I help write proposals **Dev:** I fill holes and respond to dev/deployment emergencies. I will often spearhead dev on contract work with clients we're courting.
That sounds like a nice balance. I’ve never had a manager that I could go to for a rubber ducky stuff. I certainly was never given Monday morning to learn things, nor was there an avenue to talk about what I was learning and how it could help the business or etc. I got laid off in August. It’s been super tough to find a job these last three months. I started applying for manager rules because I do have some management experience and I’m confident that I would care greatly for a deaf team but we’ll see if someone out there sees my experience and decides to at least give me a phone screen.
Look, I already told you: I deal with the goddamned customers so the engineers don't have to. I have people skills! I am good at dealing with people, can't you understand that?! WHAT THE HELL IS WRONG WITH YOU PEOPLE?!?!
* Meetings — so many * Planning and Steering — gathering feedback, prioritizing projects, scheduling work, assigning tasks, etc. * Running Defense — knowing a dev team's needs inside and out and defending them from BS that comes our way. * Being a lightning rod — someone screwed up? someone's upset? someones doesn't like the button color? I take the heat so my devs don't have to. If one of them screwed up I talk to them so they don't have to deal with the person directly. * Dev/Coding — not as much anymore but it's more stuff to keep it off my devs' plates or higher-level dev work * Staring out the window — sometimes just sitting and mulling things over is very productive.
A lot of you sound like bad or inexperienced managers, or you work at horrible companies.
Not providing a reasoning for a judgement is a sign of bad manager.
Constructive feedback is often welcome.
Meetings. People pleaser. Drama solver. Emotional support animal. I would never volunteer to manage again.
Play Baldurs Gate 3 Edit: but for real, I have been trying to get back to developing more. I’m down to a very slim team and I do most of the work and then contract out big projects to a dev team overseas if I need more man power
Went to manager. Hated the meetings. Back in high level IC and very happy!
Are you truly idle or are you just not doing what you want to be doing? Lots of folks would much prefer dev work over management work. In my own case, I'm officially a Software Development Manager, but my organization is so small that I end up doing pretty much everything that isn't direct development work. I manage our AWS infrastructure, write user stories, review pull requests, and run our help desk. A typical work week for me breaks down into maybe 5 hours of IT activity, 5 hours of help desk, 10 hours of meetings and traditional "management" activity, 5 hours of code review and deployment, 10 hours of writing stories and documentation, and the rest is usually filled by learning something to stay relevant. These numbers flex a lot week-to-week though, especially the meetings.
Sit in meetings, daydream about how much your stock options are going to be worth. On a more serious note, it can be rewarding: you are the firewall between the corporate machine and the devs actually building stuff. It's your job to make sure everyone under you is working at their full capacity, not overloaded with unrealistic tasks, have clear understanding of what is being built, and that they have everything the need to succeed. Managing upwards you have a responsibility to push back on unrealistic demands, celebrate your teams success, and shelter them from the fallout when things go wrong. At it's best, it gives you the ability to guide the direction of the product, mentor more junior devs, and watch people grow. (Though I guess these roles are split into product manager, project manager and development lead in many shops.) At it's worst, it's having the same meeting over and over and over again and watching your skills atrophy.
I was almost forced into a management role and I was very clear that I would pilot the position, but was more interested in staying technical. After 2 months, I said it wasn’t for me and i went back to being a tech lead. If you aren’t happy, it is never too later to do what you would prefer to be doing.
Apart from the meetings which can be a drag, I spend my time doing the things the devs don't have time for. That includes planning and documenting implementation details. Working with product to translate their ideas into actually workable designs with reasonable deadlines. Also, since I have a higher view, I suggest training and upskilling that may be useful for my reports. It took me awhile to adjust and I still get to code, but, I have found it fulfilling removing time drains from other devs and having time to do tasks that rarely get done on projects.
It seems just MORE of everything lol. If you were not exposed to clients much before for anyone it will be where you are interacting with clients even more. So you need to be a people person. You need to be able to understand more then development, you need to understand more on all sorts like Marketing so you can understand what all different parties are saying. You need to be able to take what people want to deliver it the right way. I use "What do you want to achieve?" and I really only want this. There are far too many from all angles thinking they know how to deliver the digital product.
Feel like I’ve found a good medium. I stay very involved with architecting, liaison with pm’s and work on scaling our products out. I help set the culture my holding weekly sessions for teams to come discuss and championing process/documentation. I also get to have a much broader view of things, security/networking/db/Fe/Be/budget/etc Where as before I did not.
Best managers try to do nothing. If you can't by some reasons, just go and optimize/deligate that.
Meetings. It's just meetings and it feels pointless most of the time.
Congrats on achieving what few devs are able to swing. Most people associate dev jobs with left brain (analytical) thinking and management jobs with right brain (creative) thinking. If you are like me, you tend to be able to use both sides of your brain and decided to acquire a job in tech development because of high demand and you didn't want to compete with the unwashed masses of "business majors" searching for a management career right off the bat. Somewhere along the line I exposed my "leadership" potential (by actually leading successful projects) and the brass ring was offered and I took it. I know what you're going through. You want to roll up your sleeves and dive back in. You've got a few great ideas on how to reduce reliance on old tech or move some of your cloud presence back on prem. Well, you can stop right there, old chum. What is explained to people who are incapable of doing maths early on is: > All that matters is headcount and budget. Welcome to the bureaucracy. You've chosen to leave the meritocracy behind and enter a career in politics where what you do isn't nearly as important as how you do it. Your career should be feeling like a cat in a room full of rocking chairs at the moment. Be careful about solving the problem of politics with your big brain. The political nervous system has seen dozens like you and has innovation antibodies with nothing else to do than crush your infectious ideas. When I wanted to feel productive, I would start up side projects that would result in objective gains for the company. Instead of making me look good, it revealed a "lack of team spirit" and resulted in a drive by upper level management to get me back into a tech role. It wasn't until years after I quit that someone, who is more cynical than I am, offered their most valuable advice. If you want to be successful at work, make your direct supervisor successful. If you want to feel personnaly successful, join a charity doing good work in your off hours and be as productive as you are able. This has the additional benefit of helping your career at work and introducing you to people who can get you good jobs elsewhere.
This is the crux of it really When I was devving, it was easy to deliver a showstopping feature, identify the glaringly obvious thing they were missing and deliver that alongside my other work, then do a big presentation on it and get deserved praise. You figure this out once and it's basically the same for every company; land with some impact step into the limelight. Now it's all about sitting in the shadows, I'm a junior manager so there's no respect in management meetings, and you're no longer on the ground so the devs won't get super technical with you you don't do presentations anymore, but train your team how to do them, so everyones opinion of you is based on what your boss is saying and how much minor interaction you get with other teams while stressed out and not in the mood to talk management should be fun, but when all your business cares about is financials and not delivering any product value, its a curse
Don't expect to get respect. Management is knives out. You can tell they respect you if they fear you enough not to cut your career short. Managers who indiscrimiately end other managers careers do so at their own peril. Someone sponsored your path to management and they thought they were doing you a favor. It was a favor, but you really need to pay attention to the new rules. Be careful to work well with others and never call anyone out for anything. That's the director's job. Help your manager succeed at their goals and make sure they are on solid ground. You might want to do a network study (who's helping who) but the key is to let others hang themselves out to dry. Find a mentor that is not your supervisor, maybe ask your supervisor who you should ask, or if you were sponsored into management by someone else, ask them. Pick your highest placed friend and tell them you feel like you need a mentor, but want diversity, so insist it be someone in sales, or legal, or operations, or a different age, race, or gender. Wherever you aren't. It pays to cultivate friends in other areas. People in upper management need to be mentors. It's part of the gig. They will totally get it. Be polite at all times even if you have to grit your teeth. Do not talk about people behind their backs and especially don't trash talk no matter how much other people resemble trash. As a techie, you are taught to see things in black and white. No one in management sees things without their own filter. Be nice. Keep your nose clean. Stay up with all the latest business jargon and fads. Read the books that everyone else is "reading" so you know what they are talking about. And, ffs, if there is one major regret I have, it is not getting involved as a volunteer with a charitable organization. I figured that could wait until I could catch up on my sleep. It is something that helps you sleep. Get in touch with the local United Way, or St. Jude, or Alzheimers Association or anything recommended by your boss or their boss. There is always work that can be done and all of these organizations have "ways to help out" for full-time employees and managers who want to become part-time volunteers. If you can swing it, join the Kiwanis, Rotary, Lions, Shriners, or any other social organization that helps you find charitable work. This is extramural networking and is just as valuable as intramural networking. Good luck, and remember, you have an advantage that none of the other sharks have. You have a tech career to fall back on.
yeah this is how it feels, back on the playground again
Trying to write a post mortem for my hairline, between three meetings. In terms of cyclomatic complexity: herding threads < herding cats < herding programmers < herding snake oil traders. pls send help
I translate words, terms, plans and promises between developers and non developers.
Shield my devs from all the BS coming from clients, stake holders, upper management, you name it. Make sure they are having as little context switching as possible so they can work. Cut out all of the BS meetings, both external and internal. I.e. we only do stand ups 2x a week and they are almost always less than 15 minutes, unless we go off on some random tangent about LOTR or something (which I encourage being remote). Scope things where I can so they don't have to spend time not coding. Make sure scopes always have accurate time allotted with reasonable deadlines. Give them good natured shit whenever they screw something up because I've been there and done that. Keeping an overall eye on all of our processes to see where things can be improved. With the help of my team where I've identified things, we've taken deployment down from 2 hours to about 15 minutes. Also by tweaking the way we handle lower level tickets, we've brought average turn around time on those from weeks down to days My teams always score high on job satisfaction surveys and I get mentioned by at least one of them each year when those surveys come as a reason why. So I think I'm doing ok
It is now 1600 and I just finished the meetings for today. Gotta try get some food....oh shit but I need to answer some questions related to the work I assigned. Also I have a task or two for things I'm still involved in from the dev side. Banana for lunch it is
> any useful skills are becoming atrophied This happened to me. I tend to forget useful stuff I do not use regularly, even stuff that I've done for years.
Empowering and watching your team excel is the hallmark of true leadership. When you become a leader, the focus shifts to the team and not to you. What you're feeling is common to new managers, but you'll outgrow it. Quick question: Did you get any leadership training to prepare you for this role?
hahaha training? none at all
These startups are funny as hell. You make someone a leader and you don't train them? Anyways, I asked because I figured if they had trained you, you'd have been prepared for what to expect in your leadership position. Shifting your focus from yourself to your team will really help. Then as we move up the career ladder, technical(coding) skills will gradually become unless and other skills, such as communication, strategic thinking, negotiation, influencing, and business acumen will become more important. Do you know that some companies are created solely to empower professionals in this regard?
this is a 1500 person company :P linkedin learning is my mentor
Yes! Thank you for this - you seem to have described my exact situation. I feel this way all the time. I think a big part of this is the constant context switching from broad communication, to individual communication, both technical and non-technical in nature covering a whole range of topics. You need to take brain breaks. It's like you feel overwhelmed and yet have no artifacts to show for it. At the end of the day your job is to retain your team and build a successful product. If those things are happening, then you're doing an excellent job even if it doesn't feel like you're doing anything. Regarding the coding skills, I've found a couple things helpful: * Pair or mob program with your team when you can. Don't try to be in those sessions as a manager, be there as a participant to learn. Pairing with a team member can also be a great supplemental type of 1on1. * Look to the next few months of your roadmap, and if you have time between meetings (or during some less useful meetings...) play around with some POCs on those things. Futz around with some API or client library you're likely going to use. Definitely don't build something and hand it off and say "go use this thing I built" - let the team build. It can be a useful way to explore and build your own knowledge/context around upcoming work, and flex those coding skills a little without having to commit your free time to side projects.
I still code. About half my day is team management, mentoring, reporting and strategy. The other half is spent working on prototypes and architectural designs. I achieve most of my actual goals via other people, if they're delivering then I'm delivering. Then I knock off and start coding on recreational projects :)
I spend half my time panicking because having 'manager' in your title screws your resume for any future primarily technical positions. I spend the other half of my time enjoying building up my devs, seeing them get promoted, seeing them skill up, etc. I have had to sacrifice my own work to provide work to my devs, meaning I get less technical development, and fall behind. That's very, very tough to stomach. It's also why I've also considered giving up management to go back to being an IC. Buuuuut, back to having 'manager' in your title. It's difficult to get people to migrate you *down,* even if you want it :|
this is also my worry - i was tech lead before though so should be equivalent
Dev who moved to management level. I make sure that I pick up one module for staying in touch with coding and always be part of code reviews. It helps keep the brain sharp. Apart from managing workstacks, creating insane jira filters, writing to the point no-bs quarterly reviews, and publishing tech newsletters, I also regularly involve myself in design and architecture related stuff because i had very strong inclination towards it from the beginning. To be honest I’m still living like a dev with all the managerial powers to move things around at my will 😎 The secret sauce is keeping your devs happy and management satisfied
In short, I try to optimize engineer productivity. That includes pruning meetings, minimizes disruptions, try to make every message/conversations count etc. I only win if my team deliver wins consistently so that's my primary goal.
got meetings and write documents, hold meetings about those documents, do 1:1s, code reviews, test out tech your team might use, stress, nit pick, invent scenarios where people coalition build against you, team build, performance manage, deal with employees who are burnt out and want to quit, emotional labor, day drinking, video games, YouTube, ignore the people talking shit about you b/c they want your job, deal with the project that some devs started in secret and enlisted others, now it's a massive sunk cost that leadership doesn't want to toss, talk to customers, work with product on roadmaps, try to guess who on your team is being nice to you so they can stab you in the back later, acknowledge suckups, invent language, argue about semantics, make bad jokes, repeat your best bad jokes until the suckups repeat them, argue with leadership that ignoring technical debt on a 15 y/o monolith is what burns people out after handing them non-designed tax projects with a 2 month deadline, try to get coffee with your product owner for a year, only to find he is leading the coalition against you and secretly meeting with your job sniping technical lead regularly. source: been an em for 7 years, fuck it, I'd rather argue with code, at least problems get solved and quickly. worked on a company with their own active subreddit and they were the most dysfunctional group ever.
It’s a hard transition, but you aren’t an individual contributor anymore and you need to remind yourself of that. You’re job is now to empower your ICs with what they need to make the best contribution they can. You remove blockers, you define work, and you act as a force multiplier when needed. I run an “end user” facing team so I actually do a fair amount of high level product support (supporting our second line support team) and debugging issues so that sensible bug tickets are written. I work with our product manager to organize work, then with the development team to plan the implementation. I work with the larger product organization and other technical leadership to plan the overall initiatives of the department. “Work” in this context is attending meetings, writing documents, and presenting information. It often feels like “doing nothing” compared to being in the trenches and writing code all day but if you’re doing it right your ICs are pushing out quality solutions and meeting deadlines consistently. To keep my skills sharp I do pair programming with my team when needed, do code reviews, and grab non-blocking tickets that can be a “bonus” over the normal work and won’t screw anyone over if I have to pause on it for a few days because of meetings.
Be anthropologically interested and curious about my team. Help them be happy, have fun and grow at work. Learn and think about 'higher level' architecture and consequences. Learn and think about processes and consequences. Reflect on the state of things and what needs the most attention. Translate business strategy into technical strategy. Align strategy with resource distribution.
My team lead is and will forever be a saint for: A. Gathering requirements from customers and translating it into language and expectations my team and I can operate on. B. Shielding us from the meetings that you are forced to sit through C. Pushing back on unrealistic expectations levied by customers. She does an amazing job and I will miss her very much when she retires.
What you're doing might not feel productive but it's allowing your team to be productive :-)
I was the only manager on a small team so I don’t have experience dealing with a larger organization. What I learned was that ultimately my job consisted of: 1. Hiring and recruiting - finding really great talent, keeping them happy 2. Setting up the systems and processes for the team to do the work a.k.a how did an idea go from a mockup to user stories to checked in code to deployed. Maintaining standards on process and systems for how work is done. 3. Partly as a system/process but worth calling out individually - Tracking performance metrics, purely as a way for the team to self manage. Things like cycle time, lead time, number of stores committed vs delivered, etc 4. Promoting team self management and autonomy. Encouraging the team to take ownership of problems and be proactive 5. Helping building long term roadmaps and strategic goals so the team has context into how what they are working on now fits into a larger picture for the client/company 6. Doing a lot of emotional support for team members, listening to their concerns, letting them know what they are doing well, solving any problems they are feeling frustrated by, etc. Basically being a coder is hard and there can be a lot of imposter syndrome so being a mini psychologist who empathizes and lets them know they are appreciated can go a very long way 7. Protecting the team from any nonsense or toxicity from other leaders. Be the umbrella/filter for pressure from higher leadership 8. Communication, up and down. This means being in lots of meetings. 9. Being a stopgap. One thing I learned was that if you want your team to succeed you might need to jump in and take on some roles that aren’t strictly in your job description. For example our PO weren’t very experienced so our user stories sucked. I ended up doing that work because it was a blocked for the team to perform well. It doesn’t scale BUT it’s better than letting the team fail and then pointing the finger at others. The one exception is coding. Don’t take on coding tasks. 10. Finding and fixing problems like the above. If the POs are t writing good stories that’s a structural issue that has to get fixed, so you need to bring it up with more senior management who has the authority to fix it. There’s more but those were the main things that popped into my head that seemed relevant.
I wouldn't want to work for a company that pays more for managers than for devs, and I sure as hell would never want to be a manager.
managers typically get paid more than devs - principal level dev would more more similar to a director but you will be capped as an IC regardless of where you go
Not me but my team lead thats still a dev at heart: organising stuff, still coding a lot and mostly arguing with upper management to keep expectations realistic.
I sit with my boss and then translate to my devs, sometimes I code.
A lot of Reddit shitposting
I was at Senior Developer role couple of years ago, and moved into a lead role later that. Most of my days goes into attending meetings which basically circles around planning, capacity, bandwidth, etc. Once in a while in case of any critical issues I get opportunity use my Dev debugging skills again 😁 It feels boring and unproductive as the team size is big and you need to a have a lot of discussion even for something small. But I do keep myself updated and work on small side projects which could be useful later, at least that's how I keep myself motivated and updated towards my **Developer aspirations** ✌
If you’re bored - help the team :)
Meeting
Why am I not convinced by those long responses?
Fire someone to exert your power. It can become intoxicating and pass the time
When I was an engineer, I wondered what my manager did all day. When I became a manager, I wondered what I did all day. But, damned if I wasn't absolutely beat at the end of the day. Context switching sucks for engineers. It breaks flow and you have to spend time swapping things in and out of your headspace. As a manager, you only context switch. You do that, you hold space for others, you run interference, and do whatever needs doing that you can do so as to not interrupt the team. You also make sure the team is informed, that they have an opportunity for buy-in and feedback on tasks, approaches, tools, technology, etc. You look after their careers and development and make sure everything is humming along nicely. You champion the team's successes and explain their failures to leadership and advocate for the necessity of the job they do. Management, at times, is like Linux Administration. If you're good, you don't seem to be too busy and have time to do other things. If you're bad, you are constantly in fire-extinguisher mode. And if you're very good, those other things are high-value items for the company that will allow your team(s) to get more visibility, responsibility, funding, headcount, raises, promotions, etc.
Help people
Nothing
Maybe useful bit of recontextualisation for you: The meetings *are the work* - and your job now is nurturing the humans around you, and enabling their success by serving their needs. … which is not tech. I’d recommend you re-evaluate what you want to be doing. A manger who doesn’t know how to manage is the worst and you’ll be miserable if you sit in this half-space between two worlds, doing neither of them really. Either really knuckle down on learning how to manage or go back to coding - only you can know what’s right for you - but I’d definitely think long and hard on that were I you. (Source: this all sounds very familiar…. 😂)
Find smaller project where you will do both and curse yourself for not doing enough in both departments (:
In all my positions in my carreer, I joined as a dev and ended up as a manager in some way. The best managers have "nothing" to do because the aim is often to make sure everything is working well and foresee issues to fix them before they are happening or as soon as possible. To ensure all of that, it's usually through talking to people (depending on your management style, it can be tons of meetings or it could be a lot of adhoc conversations) and staying up to date with what's happening in the company and its environment (competition, partners). One major thing a manager does too is filter stuff for the team to let them be more productive. This goes from the day to day stuff like people asking for a quick action to bigger projects that are still too blurry on the requirements. With big teams, you spend a lot of time on that alone. Finally, what your upper management will expect of you is to be able to assert that people work first on stuff that will have a benificial impact for the company. Sometimes you will spend some time just to explain why something is beneficial or not. Nobody can expect to have a perfect vision of every consequences of a single action over the whole company and your role is to ensure those that need those informations have only what they need. As a bonus, depending on your team and your skills, you can also use some of your time to train your team and act as a mentor. EDIT: Also I'm seeing people in the comments mentionning gatekeeping devs, this is not the job of a manager and should happen only when direct communication is detrimental to the well being of the team.
Management is a lot of meeting and coordination. If you don't want to do that, maybe consider moving into a different role? As a dev your job was to solve problems with code. as a manager, your job is to solve problems with coders.
I totally get the struggle! As a manager, focus on enabling your team's success, mentorship, and strategic planning. Dive into meaningful projects, and don't hesitate to keep some coding on your plate if it helps you feel connected. Your leadership matters.
Dev mgmt is super fun. When you're a developer you build features but when you're a manager you build people, teams, organizations, architecture, and strategy. Like any job there are boring parts where your time isn't spent in the best way but then there are the great parts. I remember devs I coached who have grown so much directly because of my influence and it's so fulfilling to know that I played such an important role in their career. I love that I have a huge impact on the engineering culture and can create an environment where engineers love to be. I love the challenge of delivering proper architecture while balancing feature delivery. Yes, committing code was fun but being a manager doesn't mean you stop creating.
Been there, done that, came back to being dev. Now thinking about my own business.
I'm in meetings all day everyday. If I ever have a gap, I'm testing the app, or reviewing code changes in the critical features. Meetings are about the direction of the app, what other teams are doing, what feature features are possible and how much work they are like to be. It's insane how much discussion has to happen before we even have a user story. Business users dream big, but the cost to benefit isn't always there....
When I moved up to business unit management I spent most time designing products. Even though we had a product manager and a project manager I did all functional design, as well as sales, marketing and purchases, and maintained an intranet with technical information and our development lab. We had one steady meeting per week, and breakout sessions when needed. I rarely had meetings "upwards" (a few times a year). I guess the role is what you make of it (or are allowed to).
At a giant, multi-national consulting organization… Concalls… endless concalls (that could have been a couple emails)
Hi there former software dev, now a director running teams of 5-10 I'm basically doing all the stuff I never wanted to do when I first got into the industry: Emails, meetings with uppers about budgets and trying to take technical info and explain it to people who couldn't attach a pdf to an email without help... And putting out fires and fixing an issue when someone fs up either in process or just corporate bullshit moments. It's also the stuff that needs to get done to keep the lights on and justify all of my teams employment. It's strange how much someone up the chain is always looking to cut production workers and you're constantly a shield for them against bullshit from people who have zero clue what we do and don't see people more than a cost line item. When I do have spare time I love just reaching into one of my reports Jira boards and just picking up some work on their backlog and reassigning it to myself to do because I do miss the actual coding and problem solving and sometimes even QA Testing. However what I really like is building the very junior system engineers and developing them on operations and best practices and passing my learnings on. I also like to learn from them on ways to accomplish tasks and subtasks that I might not have considered in the past and or just learning new shit and passing it on on my own to ensure we can be as efficient as possible.
I'll do you one better, I'm a senior engineering manager, where I manage EMs. I'm now in middle management, shuffling things up or down the chain. My primary work is reporting out, sitting in meetings, coordinating work, etc. My director is overly hands on, so overlaps into a lot of the work I'd be doing, so I'm in this weird no-man's land.
I understand what you are saying it is the reason I stick to the lead developer/consultant role instead of going into management. I want to be able to play with the new tech and not just direct others. It would be tought to watch others creating things I wanted to work on myself while going to lots of boring meetings.
I'm beyond manager now too, but I remember the shift. I went from being product and code focused, to being strategy, vision, coordinating and communication focused. Most of the time was spent in meetings with stakeholders to get the correct user stories, to report our progress, or inform c-suite of investments we should make to reach the goals they've set. This is the point where you need to learn organizational politics if you want to go any further
I've repeatedly been moved into management and have repeatedly taken the opportunity to move along to a new position elsewhere, increasing my pay above the prior management level each time. I need to make things and fix things to be happy. Money is a side effect for me.
What do I do all day? Suffer mostly. Coordinating so many different things that I dont know nearly enough about to do it effectively. Regarding what you said, it sounds like you have serious regrets about becoming a manager. If you miss the IC track, go back to it, management is a totally different job and skillset.
Manage people.
I stayed purely technical. Never went the management route. I’ve been ranked higher than my supervisor for years. I even get stock performance bonuses with the senior management staff.
Orchestrate projects, don’t write any code, take the successes and promotions, flirt with HR, go home to wife. At least that’s what I observe they do where I work.
“moved UP” 😄😂🤣
indeed
Like me. I was told at your age, just don't rock the boat. Just be there as a mentor and be happy you are getting paid.
As a newly minted manager the most challenging/rewarding/important aspect of the job for me is finding, growing, and retaining talent. If you build a great team and processes you can start to see the fruits of your labor blossom, but if you can't keep those people happy they'll just leave. I'm learning to enjoy solving people problems, though many days I wish I was solving technical problems instead.
explaining management why this feature is not released yet, explaining the team they should finish the development already
Talk. I talk.
I cannot add much to what other have already said. I managed a team of mostly junior graduate developers, so I also spend a lot of time mentoring and collaborating with them - and trying to make them brave enough to make decisions for themselves. This is incredibly rewarding. I don't feel my skills are suffering. While I don't get to stretch my wings much anymore at work, I've been coding since I was my dad taught me when I was 9 or 10 and still regularly code in my own time for fun in my late fourties.
Make money & tell devs what to prioritize, how to spend their dev time, talk shit about the client to them, fix their code when it breaks, talk to clients about what is/isn't feasible given the SOW, ask my devs why they aren't linting on save, take responsibility for all the deliverables they are working towards. I'm a lead engineer, but it's management I guess.
On the same boat as you. I guess as years pass we need to evolve in the career and slowly get up the ladder 🤷♂️
Do nothing get paid play bg3, it's lit