> Business types with none to little engineering experience should never, under any circumstances, manage engineers
In my experience as a developer at a bunch of different companies, the worst managers have actually been the opposite -- they were ex-engineers who knew nothing about management and decided to become managers for the wrong reasons (small raise, more power, etc), and had no passion for management. The longer one's career, the more one comes to respect managers, I think, and understand what a skill it is unto itself. Many young engineers have times when they feel hostile towards management or even the idea of having a "boss" at all, but that just makes the situation worse. One needs to have a more collaborative attitude to succeed. Again, it's the ex-engineers who think managements is just "common sense" are the ones you need to steer clear of.
Recently I interviewed with a company that had promoted their Senior Dev into a management role.
When a company VP emailed this guy to say a website form wasn't working, costing the company tends of thousands of dollars every day it was down, his response was, "Thank you for alerting me to this situation. I will process your request and respond within 2 business weeks."
Obviously, they'd taught him that boilerplate to help him adjust to interfacing with the business, but he lacked the common sense to realize the house was on fire.
They also said he preferred honing his coding skills and being perceived as a 'master developer' but couldn't quickly produce a list of in-flight projects, and that things were way behind schedule.
Having a bad manager who's a business type does not mean you don't need managers or all business types are bad managers. I mean, what's the sample size you're working off of? Less than 10?
I know it's unpopular on HN and elsewhere to stick up for business types at the perceived expense of engineers but managing people is a very hard thing to do, and the skills that make a great engineer too often make for bad middle-management, IMHO.
Totally agree with you on this point. It’s easy til it’s your job.
I’ve seen so many programmers put in positions of authority that were just disasters because many programmers are used to having full control of a system.
The transition usually boils down to people who believe in rigid control vs people who believe in tuning the environment to help others be more effective.
Rigid controllers are generally terrible managers. Environment tuners are essentially trying to serve other employees and the business by making it easier to do their jobs.
In addition to that, it's been my experience that their Engineering skill diminishes over time, like any other skill that isn't getting the maintenance that it requires, and they seem to be largely unaware of that. Despite their now-undersized technical knowledge / capabilities, they can still be found forcing technical decisions against the better judgement of their departments actual technical leadership. I've also had this same style of manager become a rate limiting bottleneck by forcing _all_ cross-team decision making to route through him. We gamed that, of course, because we had to, but it was still tacking days on to "decision making" that we had to suffer through just to do our jobs.
Want to watch an Engineering team go from: can produce and deliver to doesn't have a clue? Just get yourself a couple of these jokers to be your Engineering teams management.
> I've also had this same style of manager become a rate limiting bottleneck by forcing _all_ cross-team decision making to route through him.
I've seen that work incredibly well when the manager in question did keep up on his technical skills.
It can result in a very well designed and consistent system.
It also burned out the dev manager in question after two and a half years.
A strong talented leader can make a huge difference. Applying the lessons of the past means a lot of engineering mistakes can be avoided.
Also, at some point, decisions do have to be made. There will be a disagreement on the team about a direction to take, and having a benevolent dictatorship becomes very useful. Especially in a corporate setting where forking and doing both paths can be disastrous (both paths get underfunded and fail), or just not viable.
I had former-engineer managers, who were the first to acknowledge that their technical skills weren't up to date. It makes a huge difference if you can explain a technical problem to someone who has solid base skills in the field or if you have to dumb it down to layman level.
I'll second that. The worst I've seen have always been engineers or developers who felt that seniority, in terms of years on the job, entitled them to a management role regardless of any ability or training for it. They inevitably engender a tremendous amount of friction and resentment in their peers and subordinates.
As for younger developers, I manage several right now. Showing them that a management role isn't about "bossing people around for the sake of it," but more about handling different areas of responsibility needed for projects to succeed - some technical, some not - really works.
I would like to get a bit of HN feedback on the matter. I am exactly the person mentioned here - an engineer who knows nothing about the management, but because company is growing and we're hiring new people I'm slowly transitioning towards a management position. Just like you've stated I know nothing about the management and all I have is a common sense to guide me which I'm afraid is not enough on multiple occasions.
I'm especially afraid of too much micromanagement, but I don't really know how to handle the process better. Here is my style of management, briefly summarized:
I have a very deep and detailed knowledge of all of our codebase, which is in it's entirety shared by noone else at the company. I've written half of it myself and the other half has been written by other people. Most of our hires have been hired between a year and few months ago (company is very young by itself).
What is the usual process for me is that I discuss the general direction and required features with top-level management, who is entirely nontechnical and make a roadmap in my head with plans for the "subprojects" which are more or less self-contained units of work, their time estimates and relative priorities with respect to company-wide deadlines.
Based on the last two, I dispatch the tasks to relevant people, waiting when they finish previous tasks. I try not to stress people with too many tasks at once, but treat "tasks" more like a priority queue, where when a person becomes available a current highest-priority task is taken out from a queue and assigned to a person, taking into account personal technical strengths and weaknesses as well.
Most of the time, when giving a task to a person, I already have solution implemented "in my head" and the process mostly revolves around me explaining the relevant part of the codebase to a person and detailing the solution I've envisioned with special emphasis on the parts where a mistake is more likely to be made. After the implementation is done, I take part in testing and perform a code review before merging the code in the production branch.
Sometimes I wish I would give people more freedom, but on the other hand maintaining project coherency and keeping a single direction for the whole team I feel requires for me to make final decisions quite often. I plan to hand off ownership of certain "modules" in some time in the future, but first I'm waiting for deeper understanding of the codebase to develop in the reports.
On the outside, to me, it seems that the process works. People are not complaining, team makes progress, features are done on time and seem to be of satisfactory quality. But like you can read above, I'm base strongly on detailed technical knowledge and basically "planning the work ahead" for the people.
I would really appreciate if anyone could share their experience with making that transition.
I would suggest to you that perhaps a good place to go from where you are is to start getting input into your solution from your new team mates. This allows you space to guage their quality, and make them feel like their input is important, as time moves on, you will then be able to understand where the good people lie, and hopefully allow you to give them more control.
This is the kind of thing that will probably lead to your team being able to grow and feel empowered, and hopefully mean that you can take more time to carry out more managerial responsibility, and give you trust in your team. A secondary advantage is that you let go of being the some holder of all knowledge, which could burn you out in the long term.
Also, perhaps allow code reviews in both directions, as it means that you can see how your input had made them look at other people's code and choices, hopefully giving your business the ability to self manage and to ensure that practises are followed consistently, even if your eye is not on the ball at all times.
This kind of thing had helped me make the transition, although I have to admit that taking my eye of the ball sometimes for too long has led to bad code in our projects and codebase. But that's where you go back and share that with your team, and those that may need greater support. Just remember you are one person, so don't expect to carry out all the work by yourself, empower those around you and give them greater fulfillment over time.
I'm basically the same, maybe a little less on the actual technical direction. What I feel is the biggest disadvantage is that you are the bottleneck for anything to move forward. I'm not sure yet on how to solve that.
A few changes you could try:
- have the developers make their own estimates
- instead of explaining all relevant existing code, only point to where the relevant parts are or what terms to search for)
- if there is a designer involved in the features, try to get them better at making specifications, so developers can work directly with the designer instead of having you in between doing 'translation'
I don't have much more experience as a manager than you do but here are some thoughts.
1. Share the roadmap with your team once confirmed by management
2. Don't force your implementation on the team but let them come up with it and use it as long as it is good enough
3. The time will never come that you feel that your reports are ready for hand over - it will only come by necessity when you are asked to take on more responsibilities so that you have no choice but to hand off this work. So, you may as well start the hand over today as there will never be a better time.
This sounds like the rantings of someone who has had some pretty bad managers and has never managed anyone else.
My schooling was Computer Engineering, my career started as a Software Engineer and has wound all the way up to Director level. I’ve been on both sides of this equation for a long time.
Your typical “just a manager” has to spin so many plates and babysit so many people that most real “engineer types” would loathe the job and frankly, not be very good at it. I struggled mightily as a team manager where there were a lot of competing priorities, personal issues, and directions that I needed to follow. As I got higher up the chain of command the job got easier, I had less direction I had to conform to, I was thinking architecturally and in longer terms– and I didn’t have daily interpersonal drama to deal with.
Management isn’t for everyone, engineer or not. It’s a lot like parenting: Most people are just making it up as they go, trying their best, and the best ones generally put others before themselves.
Put the idea that Engineers should be these lone wolf rockstars that just to get to do what they want, regardless of corporate objectives or market positioning is ludicrous.
As an engineer, I can confirm that we’re just as short sighted and dismissive of other people’s work as they are to us.
I tend to agree that managers of engineers should have engineering experience. I think my reasons would differ from those of the author and many other engineers: it's much less charitable toward engineers. One of the best reasons to select managers who have been engineers, in my opinion, is because they know how much bullshit engineers engage in with respect to fad chasing, bikeshedding and other negative practices. It's important to know what the work of an engineer really entails: that includes the aspects of it that negatively impact the business and how as much as it does the aspects that contribute value and how.
I've seen such a thing, taken to an extreme where lazy, underskilled developers were running the show; overcomplicating, underdelivering, yet showered with praise -- and it's horrible to witness. A word of warning for anyone entering such a world: you will not change this environment and any attempts to do so will trigger an immune system response. The developers and clueless managers will circle the wagons in defense of the existing culture.
Lesson learned: don't interfere with "resume-driven development" organizations.
I suggest the following interview question: "Tell me about the technical capability of your management chain."
> I tend to agree that managers of engineers should have engineering experience.
What about managers who have had experience like a decade ago and don't do much tech experience anymore.
I am stuck in such management chain at work where some guy up top thinks he is technical enough to dictate solutions based on couple conference youtube videos that he watches.
Half knowledge and false sense of technical prowess is more dangerous imo.
A manager should not be dictating architecture unless it’s some really small operation, and even then, it’s dicey. Rather, anyone who is capable of writing up a white paper that describes the problem, solution and rational for the choices should be able to propose a solution, and then have a meeting to discuss and decide whether to move forward.
A manager should have the big picture and communicate it to the team. Then you could avoid a team member wasting time on something that’s not in the greater objectives or roadmap.
> What about managers who have had experience like a decade ago and don't do much tech experience anymore.
Do you think any of the "bullshit engineers engage in with respect to fad chasing, bikeshedding and other negative practices." will change in 20 years?
Its been almost 20 years since first coined and we _still_ have bike shedding problems
Most of the technology in use today isn't that different from what it was 10 years ago. It's a bit faster and has slightly different packaging. Any manager who last did engineering as an individual contributor ten years ago should be perfectly fine engaging in a technical discussion today at the level a manager should be doing so.
This is a valid point. In my mind, ideally, at least one or two trusted members on the team can help with this since they're even closer to the actual engineering taking place. It's helpful for management to understand the tradeoffs that are discussed, so I agree that some experience is very helpful, but hopefully the team has a few mature members as well.
I've worked along-side and led multiple managers and have experienced various types of managers.
The good ones usually stood out. A good manager is usually the ones that shield their teams from the onslaught of clients' un-managed demands. She is the one that liaises effectively between a looming deadline and the sanity of the team. She is the one making sure the clients are making their timely payments when the work is delivered/deployed or milestones met. She is the one who knows the right way to calm down an angry client when something is not happening the way it should - missed deadline, bug regression. A good manager knows her limitations, and also her power.
A bad manager is usually the one that instigates one against the other. Takes credit and sweet talks with the upper management. She blames the team when things go wrong. A manager, who reports to me, once told me, "why should I be the one to say anything now, the client is pissed and we missed the deliverables. I'm not responsible." (btw, he was fired the following month.)
I believe I'm technically sound, know a thing or two about design and I've led multiple projects with multiple project/product managers. I love the ones that are ready to go with me frontal assault on problems and challenges.
Engineering managers are a good fit for an all-out engineering team. But at the end of the day, I believe managers need to be better human characters, have empathy and have more of people skill than technical or design skills. Design/Engineering — that is what the team is for.
>have empathy and have more of people skill than technical or design skills
The problematic ones i've seen had some people skills, or they were thinking they had. The problem was when they did not understand engineering problems, and were thinking that everything was a people problem/issue. So they either assume that the developers are lazy, or they simply can't accept that the engineer can have some real objective concerns. So its either they don't understand however hard you try to explain or they try to understand it is a people/personal problem, when it is not.
Experienced managers do have an idea of engineering problems because they have seen it before - seen it happen, seen it solved, et al. A manager that does not appreciate engineering problems either just graduated from a management course or is someone who never got involved deeply with a team.
A manager has to answer to multiple people — clients, upper management, stakeholders, Jira. Unfortunately, she is totally dependent on this teams to get things done. She is utterly handicapped when it comes to doing anything useful, read, "engineering". Which is when most managers break and shows their character — they either break, blames people, do not listen, do not understand or they figure out who can help, seek help and find the right person to get things done.
Well, engineers, sometimes get it easy — they just have to solve a problem and make 2+2 = 4. They answer to one person; perhaps the manager. Think of the manager and to whom she is reporting and taking the fall. If the team does not get things done, they're the ones usually blamed.
In the early days of my career, I used to think that managers, middle managers are pretty useless. Now, I believe everyone has their roles to play a part in the whole machinery of 'the cogwheel'.
> can't accept that the engineer can have some real objective concerns
This is the opposite of people skills. If a report has a concern that doesn't seem to make sense, it is the manager's job to help them structure a clear explanation of the problem, help identify the best solutions for said problem, and collaborate with stakeholders to pick the right solution based on trade offs they are comfortable with. To be fair, to an entry level report, that process--unless done in a truly excellent way--often does seem like a lack of sympathy or empathy for the developer's challenge.
Serious question: may I ask why, in describing a plurality of good managers, you chose to use a lot of singular feminine pronouns and no plural gender-neutral pronouns; while in describing a singular (one) bad manager, you avoided the use of a pronoun altogether in one sentence; used one plural general-neutral pronoun in another; and then switched from using the pronoun you previously extensively used when describing good things (singular feminine pronouns), to instead using the singular masculine pronoun? I was just curious if there was a story behind that or something.
Wow! I had to read this few times, aloud. I'd love to write like this. This is cool.
Anyway, made slight normalization to the plural/singular gender usage.
Yes. I'm usually called in when things escalate either with a team or with a client. So, one late evening (early morning for the client's timezone), I joined a client call with the team leads, including the project manager (hired about a month or so ago). The project managers keep eluding anything that goes to him, was evasive, keep blaming the team. I decided to cushion the blame, apologize to the client from the team and promised to be in direct call with him until the problems are solved. Luckily, I was able to rally the team, beg/borrow other guys from other team and turn around in few weeks. I confronted the manager (after talking to everyone in the project), asked him what he wants from the team, from his life, how does he really want to execute his role. Didn't go well. I think, I might have gotten him fired. In my defence, that was a good decision for the team and the company.
Serious question: Why does it matter? The masculine singular has been used through most history and in modern times it is as acceptable to use the feminine singular as a "general case" pronoun. His specific example was obviously about an actual, specific man.
I wrote 1000 words on this subject and prior spectacular failures of the "no management" style in Silicon Valley. I deleted it. No good can come of talking about it here.
Instead of an essay, I'll use a modern writing format: the pithy list.
1. This article gravely underestimates the difficulty of engineering management. One must simultaneously handle HR functions, he roadmap of their team and other teams, and their reportee's opportunities for growth and success. It's a very complex juggling act that most people are thrown into with no training, because training for the technical aspects is so bad.
2. This article's author forgets or is simply too lazy to look up previous examples of failure. Further, they're ignoring other attempts to systematize an "unmanaged" environment and what challenges people face there. It's unfortunate that they chose to pen such a long and effort-laden essay without doing sufficient research first.
3. The author of this article also seems to totally ignore the coordination and management functions required of microservice organizations. Presumably because as an engineer who specializes in delivering one single single-purpose executable on top of everyone else's microservice architectures, they may not have a ton of experience with it. Who is doing this if not engineering managers? Product managers can have some mechanical sympathy, but it's seldom their job to deeply roadmap out features.
4. This article ends suggesting that you don't need engineering managers to deeply understand the larger technical roadmap for your company and translate it to your team, but might find room for process custodians like scrum masters fix this problem? What? What even? This isn't even wrong. This is tantamount to suggesting the engineering itself doesn't even matter! It contradicts at least half of what the prior argument said.
> I wrote 1000 words on this subject and prior spectacular failures of the "no management" style in Silicon Valley. I deleted it. No good can come of talking about it here.
Well, put it this way: I've worked in more- and less management-oriented companies, and have found that those that were less heavily managed were both better working experiences for me and more effective as businesses.
> 1. This article gravely underestimates the difficulty of engineering management. One must simultaneously handle HR functions, he roadmap of their team and other teams, and their reportee's opportunities for growth and success.
If managers fail because the role is too hard for them, we can't expect to get better people, we need to make the role easier. Some of those activities can be separated (e.g. having distinct "team tech lead" and "team line manager" positions), line employees can be empowered to do some of them themselves (personal development), and some simply don't deliver enough value to be worth doing at all (maintaining technical roadmaps).
> 2. This article's author forgets or is simply too lazy to look up previous examples of failure. Further, they're ignoring other attempts to systematize an "unmanaged" environment and what challenges people face there. It's unfortunate that they chose to pen such a long and effort-laden essay without doing sufficient research first.
I think it's entirely reasonable for them to write from their own experience rather than mixing first- and second-hand information in the same essay. Their essay makes a positive contribution to the conversation; concrete experiences of failure of alternative approaches would also be a positive contribution (far more so than low-content "they didn't research" complaints).
> 3. The author of this article also seems to totally ignore the coordination and management functions required of microservice organizations. Presumably because as an engineer who specializes in delivering one single single-purpose executable on top of everyone else's microservice architectures, they may not have a ton of experience with it. Who is doing this if not engineering managers?
You're putting the cart before the horse there; in my experience a vertically-layered "microservice organization" like you describe is the product of overmanagement (Conway's law in action). Better to give teams responsibility for delivery of client-facing functionality and have shared ownership of any common code; you write the functionality you need for the features you need. If you have a layer that really creates enough value to be worth other teams using it as a product, treat it as an actual product (ideally make it an actual product that you sell), and have a client-vendor-like relationship. Otherwise, a certain level of duplication of effort ends up being much less of a cost than constant between-team coordination would be.
> Product managers can have some mechanical sympathy, but it's seldom their job to deeply roadmap out features.
You don't need a deep technical roadmap, only a product roadmap, because you integrate with other teams at the product level, not the deep technical level. Even in the presence of relatively good management I've found that that's what works best. Think Amazon's famous "platform memo".
(Of course occasionally a specific feature will require deep technical coordination with another team. But that coordination is best done by the person with the responsibility for delivering that individual feature - the line worker.)
> 4. This article ends suggesting that you don't need engineering managers to deeply understand the larger technical roadmap for your company and translate it to your team, but might find room for process custodians like scrum masters fix this problem? What? What even? This isn't even wrong. This is tantamount to suggesting the engineering itself doesn't even matter!
Engineering matters, but planning of engineering has been a counterproductive activity every time I've seen it attempted. Planning and management should be done at the feature level; when it comes to the technical "architecture", trust your technical professionals to figure it out themselves - they're the people who will have the information they need to make those decisions. Software architecture is a lot more flexible than people tend to think; even on a large codebase delivering complex functionality, it's surprisingly easy to make radical architectural changes, and often the biggest impediment to those is well-meaning "architectural design" that exists solely due to management imposition rather than being driven by any actual functional requirements.
> If managers fail because the role is too hard for them, we can't expect to get better people, we need to make the role easier
Or maybe we need to start recognizing that engineering
management is a thing that has value, requires training, and is distinct from being an engineer with a strong personality.
It's telling to me that rather than elevate the role you're more inclined to destroy it.
> Their essay makes a positive contribution to the conversation
If this weren't a post-Zappos, post-Github, post-Uber world it might. As such it reads like a stale take from 2009, to me. But sure, we can just ignore the cycle of failure in the industry and keep writing the same stale think pieces. Hey check out my fresh new monad tutorial while you're at it, Monads are like burrito aquaducts where the black beans and delicious salsa flow from computation to computation across the continent.
> You're putting the cart before the horse there; in my experience a vertically-layered "microservice organization" like you describe is the product of overmanagement (Conway's law in action).
I've described, with the most pessimistic lens, 2 layers of management to the top of your company, with a focus on team collaboration. Having managers with strong engineering experience and technical sympathy decreases the depth of your organization, it doesn't increase it.
Please don't misrepresent my argument in your rush to dump on the idea of management.
> You don't need a deep technical roadmap, only a product roadmap, because you integrate with other teams at the product level, not the deep technical level. Even in the presence of relatively good management I've found that that's what works best. Think Amazon's famous "platform memo".
Funny then how Amazon has technical management. But as an example of planning, imagine a platform team runs a flight of APIs. There are multiple clients to these APIs all shipping products. Each has their own feature needs. If those teams collaborate on dependencies and optimize around what they need, everyone gets what they need faster. Not coordinating or planning provides a random outcome in a space dominated by sub-optimal outcomes.
> Engineering matters, but planning of engineering has been a counterproductive activity every time I've seen it attempted. Planning and management should be done at the feature level; when it comes to the technical "architecture", trust your technical professionals to figure it out themselves
This entire discussion is predicated on the notion that your managers are technical professionals facilitating this. It's weird how many people refuse to accept the idea that people can exist, while in the same forum glorifying hybrid roles like startup CTOs in the same forum who are obligated to do a lot of management functions AND be the basis of a strong technical department.
P.S., I apologise for the brevity and potential grammar errors. I wrote this on mobile, figuring a prompt response was more useful than an expansive response.
This is well-said. To add some anecdata, I work in a “managerless” organization. It sucks. It’s hard or impossible to make certain changes because nobody has any authority to do things that aren’t necessarily politically sexy (e.g. fixing bad security or setting up asset management). There’s also this expectation that if you want to do something, you can just do it. This sounds great on paper, until you realize that doing things like managing infrastructure is a full-time job for an entire team, and not a “once in a while” position for someone with little experience. I’d love to go the extra mile, but I only have 40 hours or so in my work week, and I’m busy with my actual assigned tasks.
There needs to be a good balance (obviously too much red tape is counterproductive). Having managers can be nice when it explicitly assigns roles and responsibilities to a group, because that means not only are there dedicated people for certain tasks, but presumably they have a modicum of power to get things done. It also makes it plainly obvious whom you talk to if you need, say, a new laptop, or a printer set up, or a VPN account. Without managers you get company-wide emails like “who controls our website? I need to update something.”
Sometimes we engineers do a poor job of communicating complexity: we have un-communicated assumptions that we think the listening party shares. Which sometimes lead to this:
"You could prepend the words “it’s just” to anything, it’s not going to change the fact that you sound completely ignorant and will ignore any challenges that your team communicates to you."
I have often found it effective to counter "just-justifications" with the right representation of complexity. E.g.
"Yes, it's just an API change, but it requires 50 new test cases and impacts 120 existing test cases",
OR
"Yes, it's just a library change, but there are 450 sites in our code that use the library and out of those, 50 involve financial calculations"
Almost always, the manager appreciates this because you would have brought to his attention a problem that would otherwise gone under his radar.
He might have a point if a simple API-change impacts 170 test cases. This sounds suspiciously like "no functional tests but let's go for 100% coverage with unit tests" - not necessarily the efficient thing to do, from a management perspective.
That product owner might have a good point. Far too many engineers I know think 100% coverage is a reasonable goal and spend way too much time writing unit tests that don't add much value or worse add negative value.
Something I have wanted to ask the HN community, that this article brings up: what exactly does a scrum master do?
From what I have observed at one business, there is one scrum master on every team. Many of them know nothing about the business that business does, and have no technical background. I have seen developers spend sometimes an hour or more a day explaining to scrum masters what they just built, so that they can then go "communicate that up" to upper management or project management in opaque meetings developers aren't allowed to attend.
But what I can't figure out, is what they are actually supposed to do. At best, I see two points:
1. They do the traditional work of a project manager but on a team level, and communicate status up.
2. They are supposed to be some kind of "thought leader" on agile methodologies.
Can HN help shed some light on what this role should do? Perhaps my background has just been a bad experience in this regard. I suppose where I get stuck is, this seems to be the work that a dev lead used to do. Why make a full time job for a non-technical person to lead a technical team, below the management level?
In my company, each team has a scrum master (a SM being part of 2/3 teams). They have near-zero technical knowledge, and this is what they do (no particular order):
- Give an organisation to the team, and make sure that this organisation does not decay with time
- Help the devs work faster by helping them with the methodology
- Help identifying & solving problems (a problem goes from "a dev spent one hour more than expected on this ticket" to "the client has no vision on what the product should be"). This is probably the most important task
- Help the client to lead his project. This is a huge part too, the client does not know how to lead a project (they just came to us with a business problem they want to solve): there's no way the project will succeed if the client doesn't manage to have a clear vision for his product, prioritise tasks, build indicators, get user feedback...
Minor tasks:
- Organise meetings/demos
- Lead the meetings, make sure they're productive
We're a service company without management, "communicating status up" is a concept that doesn't exist.
> This is probably the most important task - Help the client to lead his project
For someone to do this, they would have to have client communication skills, at least somewhat thorough understanding of software development or the process, and an understanding of the client's business. I see this as a good thing. However, your example sounds to be a company that has external clients that you write software for. Do you not have account managers/principle types who interact with the clients, or is that more or less what a scrum master does there? Just curious, if you were an internal only dev shop that just develops software for stakeholders at your own company, would you see the role of a scrum master as significantly different?
I've never had a scrum master across 7-8 companies. Usually it was a rotating role, or a manager/tech lead. But certainly not one person dedicated to it.
>I have seen developers spend sometimes an hour or more a day explaining to scrum masters what they just built, so that they can then go "communicate that up" to upper management or project management in opaque meetings developers aren't allowed to attend.
Your scrum masters really aren't. The SM role is supposed to be a few minutes a day, and focus more on how people work rather than the technical details.
Examples are things like telling management that the team has often missed deliverables because a key resource (some piece of hardware, etc) is often unavailable. Or even telling managers that their employees think one of the manager's policies sucks.
To an extent, it's about holding the team accountable as well: Why are some people working on a lower priority item when no one is working on a higher priority item?
Don't get me wrong - I'm no fan of scrum, and am not saying a SM is needed. But, as with management, a good SM is a valuable contribution to the team.
While I agree that it helps for a manager to have experience doing what they are managing, I would frame it differently. I've experienced poor engineering managers with engineering experience and good engineering managers with none, to the point that I've developed a more nuanced opinion about what makes a good (engineering) manager.
Great managers can manage things they don't understand and probably never will -- their role does not require domain expertise. I would argue that the hallmark of a poor manager is that they can't manage unless they are a domain expert, which they often use as a crutch to overcome lack of basic management skill. One of the greatest failure modes for software engineering managers with engineering backgrounds is the assumption that they can or will understand every part of the design they are managing. Not only is this unlikely in many cases but this delusion encourages them to dictate elements of engineering design that they are not intimately familiar with, invariably to the annoyance of the engineers that are tasked with doing the work and may have far more technical skill than the manager on the task at hand. For mundane software projects, an engineering manager with an engineering background may legitimately have the domain expertise, which is why it still gets things done despite being suboptimal for everyone.
This is really brought to light when doing complex, high-end software system engineering. In these cases my experience is that most experienced engineering managers with engineering backgrounds fail; because it is impossible to understand what your team does at a technical level, you can't lean on that. It is often difficult for very experienced engineers, now managers, to come to terms with the idea that someone working on "their" project has technical skills that they can't master or at least understand with a 15 minute explanation and a couple hours of research. Engineering managers, especially ones that were previously great engineers, must resist the instinct to technically master everything under their purview -- it doesn't scale. The advantage of non-engineering managers in these environments is that their management style doesn't rely on the assumption that they can technically master any part of the project, so they don't even try.
A big part of being a good engineering manager is letting go of what made you a great engineer. It isn't an easy thing to do.
Readit News
In my experience as a developer at a bunch of different companies, the worst managers have actually been the opposite -- they were ex-engineers who knew nothing about management and decided to become managers for the wrong reasons (small raise, more power, etc), and had no passion for management. The longer one's career, the more one comes to respect managers, I think, and understand what a skill it is unto itself. Many young engineers have times when they feel hostile towards management or even the idea of having a "boss" at all, but that just makes the situation worse. One needs to have a more collaborative attitude to succeed. Again, it's the ex-engineers who think managements is just "common sense" are the ones you need to steer clear of.
Recently I interviewed with a company that had promoted their Senior Dev into a management role.
When a company VP emailed this guy to say a website form wasn't working, costing the company tends of thousands of dollars every day it was down, his response was, "Thank you for alerting me to this situation. I will process your request and respond within 2 business weeks."
Obviously, they'd taught him that boilerplate to help him adjust to interfacing with the business, but he lacked the common sense to realize the house was on fire.
They also said he preferred honing his coding skills and being perceived as a 'master developer' but couldn't quickly produce a list of in-flight projects, and that things were way behind schedule.
Having a bad manager who's a business type does not mean you don't need managers or all business types are bad managers. I mean, what's the sample size you're working off of? Less than 10?
I know it's unpopular on HN and elsewhere to stick up for business types at the perceived expense of engineers but managing people is a very hard thing to do, and the skills that make a great engineer too often make for bad middle-management, IMHO.
I’ve seen so many programmers put in positions of authority that were just disasters because many programmers are used to having full control of a system.
The transition usually boils down to people who believe in rigid control vs people who believe in tuning the environment to help others be more effective.
Rigid controllers are generally terrible managers. Environment tuners are essentially trying to serve other employees and the business by making it easier to do their jobs.
> Management is not a promotion. It is a career change.
http://fractio.nl/2014/09/19/not-a-promotion-a-career-change...
Want to watch an Engineering team go from: can produce and deliver to doesn't have a clue? Just get yourself a couple of these jokers to be your Engineering teams management.
I've seen that work incredibly well when the manager in question did keep up on his technical skills.
It can result in a very well designed and consistent system.
It also burned out the dev manager in question after two and a half years.
A strong talented leader can make a huge difference. Applying the lessons of the past means a lot of engineering mistakes can be avoided.
Also, at some point, decisions do have to be made. There will be a disagreement on the team about a direction to take, and having a benevolent dictatorship becomes very useful. Especially in a corporate setting where forking and doing both paths can be disastrous (both paths get underfunded and fail), or just not viable.
As for younger developers, I manage several right now. Showing them that a management role isn't about "bossing people around for the sake of it," but more about handling different areas of responsibility needed for projects to succeed - some technical, some not - really works.
In a reasonably varied group of 6-8 engineers, one in the course of his career will have both desire and aptitude for management.
Probably even more than one.
I'm especially afraid of too much micromanagement, but I don't really know how to handle the process better. Here is my style of management, briefly summarized:
I have a very deep and detailed knowledge of all of our codebase, which is in it's entirety shared by noone else at the company. I've written half of it myself and the other half has been written by other people. Most of our hires have been hired between a year and few months ago (company is very young by itself).
What is the usual process for me is that I discuss the general direction and required features with top-level management, who is entirely nontechnical and make a roadmap in my head with plans for the "subprojects" which are more or less self-contained units of work, their time estimates and relative priorities with respect to company-wide deadlines.
Based on the last two, I dispatch the tasks to relevant people, waiting when they finish previous tasks. I try not to stress people with too many tasks at once, but treat "tasks" more like a priority queue, where when a person becomes available a current highest-priority task is taken out from a queue and assigned to a person, taking into account personal technical strengths and weaknesses as well.
Most of the time, when giving a task to a person, I already have solution implemented "in my head" and the process mostly revolves around me explaining the relevant part of the codebase to a person and detailing the solution I've envisioned with special emphasis on the parts where a mistake is more likely to be made. After the implementation is done, I take part in testing and perform a code review before merging the code in the production branch.
Sometimes I wish I would give people more freedom, but on the other hand maintaining project coherency and keeping a single direction for the whole team I feel requires for me to make final decisions quite often. I plan to hand off ownership of certain "modules" in some time in the future, but first I'm waiting for deeper understanding of the codebase to develop in the reports.
On the outside, to me, it seems that the process works. People are not complaining, team makes progress, features are done on time and seem to be of satisfactory quality. But like you can read above, I'm base strongly on detailed technical knowledge and basically "planning the work ahead" for the people.
I would really appreciate if anyone could share their experience with making that transition.
This is the kind of thing that will probably lead to your team being able to grow and feel empowered, and hopefully mean that you can take more time to carry out more managerial responsibility, and give you trust in your team. A secondary advantage is that you let go of being the some holder of all knowledge, which could burn you out in the long term.
Also, perhaps allow code reviews in both directions, as it means that you can see how your input had made them look at other people's code and choices, hopefully giving your business the ability to self manage and to ensure that practises are followed consistently, even if your eye is not on the ball at all times.
This kind of thing had helped me make the transition, although I have to admit that taking my eye of the ball sometimes for too long has led to bad code in our projects and codebase. But that's where you go back and share that with your team, and those that may need greater support. Just remember you are one person, so don't expect to carry out all the work by yourself, empower those around you and give them greater fulfillment over time.
A few changes you could try: - have the developers make their own estimates - instead of explaining all relevant existing code, only point to where the relevant parts are or what terms to search for) - if there is a designer involved in the features, try to get them better at making specifications, so developers can work directly with the designer instead of having you in between doing 'translation'
1) Do they not propose tasks for bug fixes and refactors?
2) Are engineers encouraged to propose their own solutions?
3) Do you only assign tasks you know how to do yourself?
My schooling was Computer Engineering, my career started as a Software Engineer and has wound all the way up to Director level. I’ve been on both sides of this equation for a long time.
Your typical “just a manager” has to spin so many plates and babysit so many people that most real “engineer types” would loathe the job and frankly, not be very good at it. I struggled mightily as a team manager where there were a lot of competing priorities, personal issues, and directions that I needed to follow. As I got higher up the chain of command the job got easier, I had less direction I had to conform to, I was thinking architecturally and in longer terms– and I didn’t have daily interpersonal drama to deal with.
Management isn’t for everyone, engineer or not. It’s a lot like parenting: Most people are just making it up as they go, trying their best, and the best ones generally put others before themselves.
Put the idea that Engineers should be these lone wolf rockstars that just to get to do what they want, regardless of corporate objectives or market positioning is ludicrous.
As an engineer, I can confirm that we’re just as short sighted and dismissive of other people’s work as they are to us.
I've seen such a thing, taken to an extreme where lazy, underskilled developers were running the show; overcomplicating, underdelivering, yet showered with praise -- and it's horrible to witness. A word of warning for anyone entering such a world: you will not change this environment and any attempts to do so will trigger an immune system response. The developers and clueless managers will circle the wagons in defense of the existing culture.
Lesson learned: don't interfere with "resume-driven development" organizations.
I suggest the following interview question: "Tell me about the technical capability of your management chain."
What about managers who have had experience like a decade ago and don't do much tech experience anymore.
I am stuck in such management chain at work where some guy up top thinks he is technical enough to dictate solutions based on couple conference youtube videos that he watches.
Half knowledge and false sense of technical prowess is more dangerous imo.
A manager should have the big picture and communicate it to the team. Then you could avoid a team member wasting time on something that’s not in the greater objectives or roadmap.
Do you think any of the "bullshit engineers engage in with respect to fad chasing, bikeshedding and other negative practices." will change in 20 years?
Its been almost 20 years since first coined and we _still_ have bike shedding problems
I've worked along-side and led multiple managers and have experienced various types of managers.
The good ones usually stood out. A good manager is usually the ones that shield their teams from the onslaught of clients' un-managed demands. She is the one that liaises effectively between a looming deadline and the sanity of the team. She is the one making sure the clients are making their timely payments when the work is delivered/deployed or milestones met. She is the one who knows the right way to calm down an angry client when something is not happening the way it should - missed deadline, bug regression. A good manager knows her limitations, and also her power.
A bad manager is usually the one that instigates one against the other. Takes credit and sweet talks with the upper management. She blames the team when things go wrong. A manager, who reports to me, once told me, "why should I be the one to say anything now, the client is pissed and we missed the deliverables. I'm not responsible." (btw, he was fired the following month.)
I believe I'm technically sound, know a thing or two about design and I've led multiple projects with multiple project/product managers. I love the ones that are ready to go with me frontal assault on problems and challenges.
Engineering managers are a good fit for an all-out engineering team. But at the end of the day, I believe managers need to be better human characters, have empathy and have more of people skill than technical or design skills. Design/Engineering — that is what the team is for.
Edit: Plural/Singular Gender normalization.
The problematic ones i've seen had some people skills, or they were thinking they had. The problem was when they did not understand engineering problems, and were thinking that everything was a people problem/issue. So they either assume that the developers are lazy, or they simply can't accept that the engineer can have some real objective concerns. So its either they don't understand however hard you try to explain or they try to understand it is a people/personal problem, when it is not.
A manager has to answer to multiple people — clients, upper management, stakeholders, Jira. Unfortunately, she is totally dependent on this teams to get things done. She is utterly handicapped when it comes to doing anything useful, read, "engineering". Which is when most managers break and shows their character — they either break, blames people, do not listen, do not understand or they figure out who can help, seek help and find the right person to get things done.
Well, engineers, sometimes get it easy — they just have to solve a problem and make 2+2 = 4. They answer to one person; perhaps the manager. Think of the manager and to whom she is reporting and taking the fall. If the team does not get things done, they're the ones usually blamed.
In the early days of my career, I used to think that managers, middle managers are pretty useless. Now, I believe everyone has their roles to play a part in the whole machinery of 'the cogwheel'.
This is the opposite of people skills. If a report has a concern that doesn't seem to make sense, it is the manager's job to help them structure a clear explanation of the problem, help identify the best solutions for said problem, and collaborate with stakeholders to pick the right solution based on trade offs they are comfortable with. To be fair, to an entry level report, that process--unless done in a truly excellent way--often does seem like a lack of sympathy or empathy for the developer's challenge.
Deleted Comment
Anyway, made slight normalization to the plural/singular gender usage.
Yes. I'm usually called in when things escalate either with a team or with a client. So, one late evening (early morning for the client's timezone), I joined a client call with the team leads, including the project manager (hired about a month or so ago). The project managers keep eluding anything that goes to him, was evasive, keep blaming the team. I decided to cushion the blame, apologize to the client from the team and promised to be in direct call with him until the problems are solved. Luckily, I was able to rally the team, beg/borrow other guys from other team and turn around in few weeks. I confronted the manager (after talking to everyone in the project), asked him what he wants from the team, from his life, how does he really want to execute his role. Didn't go well. I think, I might have gotten him fired. In my defence, that was a good decision for the team and the company.
Dead Comment
Instead of an essay, I'll use a modern writing format: the pithy list.
1. This article gravely underestimates the difficulty of engineering management. One must simultaneously handle HR functions, he roadmap of their team and other teams, and their reportee's opportunities for growth and success. It's a very complex juggling act that most people are thrown into with no training, because training for the technical aspects is so bad.
2. This article's author forgets or is simply too lazy to look up previous examples of failure. Further, they're ignoring other attempts to systematize an "unmanaged" environment and what challenges people face there. It's unfortunate that they chose to pen such a long and effort-laden essay without doing sufficient research first.
3. The author of this article also seems to totally ignore the coordination and management functions required of microservice organizations. Presumably because as an engineer who specializes in delivering one single single-purpose executable on top of everyone else's microservice architectures, they may not have a ton of experience with it. Who is doing this if not engineering managers? Product managers can have some mechanical sympathy, but it's seldom their job to deeply roadmap out features.
4. This article ends suggesting that you don't need engineering managers to deeply understand the larger technical roadmap for your company and translate it to your team, but might find room for process custodians like scrum masters fix this problem? What? What even? This isn't even wrong. This is tantamount to suggesting the engineering itself doesn't even matter! It contradicts at least half of what the prior argument said.
Well, put it this way: I've worked in more- and less management-oriented companies, and have found that those that were less heavily managed were both better working experiences for me and more effective as businesses.
> 1. This article gravely underestimates the difficulty of engineering management. One must simultaneously handle HR functions, he roadmap of their team and other teams, and their reportee's opportunities for growth and success.
If managers fail because the role is too hard for them, we can't expect to get better people, we need to make the role easier. Some of those activities can be separated (e.g. having distinct "team tech lead" and "team line manager" positions), line employees can be empowered to do some of them themselves (personal development), and some simply don't deliver enough value to be worth doing at all (maintaining technical roadmaps).
> 2. This article's author forgets or is simply too lazy to look up previous examples of failure. Further, they're ignoring other attempts to systematize an "unmanaged" environment and what challenges people face there. It's unfortunate that they chose to pen such a long and effort-laden essay without doing sufficient research first.
I think it's entirely reasonable for them to write from their own experience rather than mixing first- and second-hand information in the same essay. Their essay makes a positive contribution to the conversation; concrete experiences of failure of alternative approaches would also be a positive contribution (far more so than low-content "they didn't research" complaints).
> 3. The author of this article also seems to totally ignore the coordination and management functions required of microservice organizations. Presumably because as an engineer who specializes in delivering one single single-purpose executable on top of everyone else's microservice architectures, they may not have a ton of experience with it. Who is doing this if not engineering managers?
You're putting the cart before the horse there; in my experience a vertically-layered "microservice organization" like you describe is the product of overmanagement (Conway's law in action). Better to give teams responsibility for delivery of client-facing functionality and have shared ownership of any common code; you write the functionality you need for the features you need. If you have a layer that really creates enough value to be worth other teams using it as a product, treat it as an actual product (ideally make it an actual product that you sell), and have a client-vendor-like relationship. Otherwise, a certain level of duplication of effort ends up being much less of a cost than constant between-team coordination would be.
> Product managers can have some mechanical sympathy, but it's seldom their job to deeply roadmap out features.
You don't need a deep technical roadmap, only a product roadmap, because you integrate with other teams at the product level, not the deep technical level. Even in the presence of relatively good management I've found that that's what works best. Think Amazon's famous "platform memo".
(Of course occasionally a specific feature will require deep technical coordination with another team. But that coordination is best done by the person with the responsibility for delivering that individual feature - the line worker.)
> 4. This article ends suggesting that you don't need engineering managers to deeply understand the larger technical roadmap for your company and translate it to your team, but might find room for process custodians like scrum masters fix this problem? What? What even? This isn't even wrong. This is tantamount to suggesting the engineering itself doesn't even matter!
Engineering matters, but planning of engineering has been a counterproductive activity every time I've seen it attempted. Planning and management should be done at the feature level; when it comes to the technical "architecture", trust your technical professionals to figure it out themselves - they're the people who will have the information they need to make those decisions. Software architecture is a lot more flexible than people tend to think; even on a large codebase delivering complex functionality, it's surprisingly easy to make radical architectural changes, and often the biggest impediment to those is well-meaning "architectural design" that exists solely due to management imposition rather than being driven by any actual functional requirements.
Or maybe we need to start recognizing that engineering management is a thing that has value, requires training, and is distinct from being an engineer with a strong personality.
It's telling to me that rather than elevate the role you're more inclined to destroy it.
> Their essay makes a positive contribution to the conversation
If this weren't a post-Zappos, post-Github, post-Uber world it might. As such it reads like a stale take from 2009, to me. But sure, we can just ignore the cycle of failure in the industry and keep writing the same stale think pieces. Hey check out my fresh new monad tutorial while you're at it, Monads are like burrito aquaducts where the black beans and delicious salsa flow from computation to computation across the continent.
> You're putting the cart before the horse there; in my experience a vertically-layered "microservice organization" like you describe is the product of overmanagement (Conway's law in action).
I've described, with the most pessimistic lens, 2 layers of management to the top of your company, with a focus on team collaboration. Having managers with strong engineering experience and technical sympathy decreases the depth of your organization, it doesn't increase it.
Please don't misrepresent my argument in your rush to dump on the idea of management.
> You don't need a deep technical roadmap, only a product roadmap, because you integrate with other teams at the product level, not the deep technical level. Even in the presence of relatively good management I've found that that's what works best. Think Amazon's famous "platform memo".
Funny then how Amazon has technical management. But as an example of planning, imagine a platform team runs a flight of APIs. There are multiple clients to these APIs all shipping products. Each has their own feature needs. If those teams collaborate on dependencies and optimize around what they need, everyone gets what they need faster. Not coordinating or planning provides a random outcome in a space dominated by sub-optimal outcomes.
> Engineering matters, but planning of engineering has been a counterproductive activity every time I've seen it attempted. Planning and management should be done at the feature level; when it comes to the technical "architecture", trust your technical professionals to figure it out themselves
This entire discussion is predicated on the notion that your managers are technical professionals facilitating this. It's weird how many people refuse to accept the idea that people can exist, while in the same forum glorifying hybrid roles like startup CTOs in the same forum who are obligated to do a lot of management functions AND be the basis of a strong technical department.
P.S., I apologise for the brevity and potential grammar errors. I wrote this on mobile, figuring a prompt response was more useful than an expansive response.
There needs to be a good balance (obviously too much red tape is counterproductive). Having managers can be nice when it explicitly assigns roles and responsibilities to a group, because that means not only are there dedicated people for certain tasks, but presumably they have a modicum of power to get things done. It also makes it plainly obvious whom you talk to if you need, say, a new laptop, or a printer set up, or a VPN account. Without managers you get company-wide emails like “who controls our website? I need to update something.”
"You could prepend the words “it’s just” to anything, it’s not going to change the fact that you sound completely ignorant and will ignore any challenges that your team communicates to you."
I have often found it effective to counter "just-justifications" with the right representation of complexity. E.g.
"Yes, it's just an API change, but it requires 50 new test cases and impacts 120 existing test cases",
OR
"Yes, it's just a library change, but there are 450 sites in our code that use the library and out of those, 50 involve financial calculations"
Almost always, the manager appreciates this because you would have brought to his attention a problem that would otherwise gone under his radar.
"See, that's exactly why we shouldn't write any/so many tests!" - A product owner I know...
IMO, a manager should understand the complexity of the work of his employee at an approx. ball park level.
From what I have observed at one business, there is one scrum master on every team. Many of them know nothing about the business that business does, and have no technical background. I have seen developers spend sometimes an hour or more a day explaining to scrum masters what they just built, so that they can then go "communicate that up" to upper management or project management in opaque meetings developers aren't allowed to attend.
But what I can't figure out, is what they are actually supposed to do. At best, I see two points: 1. They do the traditional work of a project manager but on a team level, and communicate status up. 2. They are supposed to be some kind of "thought leader" on agile methodologies.
Can HN help shed some light on what this role should do? Perhaps my background has just been a bad experience in this regard. I suppose where I get stuck is, this seems to be the work that a dev lead used to do. Why make a full time job for a non-technical person to lead a technical team, below the management level?
- Give an organisation to the team, and make sure that this organisation does not decay with time - Help the devs work faster by helping them with the methodology - Help identifying & solving problems (a problem goes from "a dev spent one hour more than expected on this ticket" to "the client has no vision on what the product should be"). This is probably the most important task - Help the client to lead his project. This is a huge part too, the client does not know how to lead a project (they just came to us with a business problem they want to solve): there's no way the project will succeed if the client doesn't manage to have a clear vision for his product, prioritise tasks, build indicators, get user feedback...
Minor tasks: - Organise meetings/demos - Lead the meetings, make sure they're productive
We're a service company without management, "communicating status up" is a concept that doesn't exist.
For someone to do this, they would have to have client communication skills, at least somewhat thorough understanding of software development or the process, and an understanding of the client's business. I see this as a good thing. However, your example sounds to be a company that has external clients that you write software for. Do you not have account managers/principle types who interact with the clients, or is that more or less what a scrum master does there? Just curious, if you were an internal only dev shop that just develops software for stakeholders at your own company, would you see the role of a scrum master as significantly different?
Unfortunately I've seen people with it as a job title. They were the absolute joke you'd expect.
Your scrum masters really aren't. The SM role is supposed to be a few minutes a day, and focus more on how people work rather than the technical details.
Examples are things like telling management that the team has often missed deliverables because a key resource (some piece of hardware, etc) is often unavailable. Or even telling managers that their employees think one of the manager's policies sucks.
To an extent, it's about holding the team accountable as well: Why are some people working on a lower priority item when no one is working on a higher priority item?
Don't get me wrong - I'm no fan of scrum, and am not saying a SM is needed. But, as with management, a good SM is a valuable contribution to the team.
Great managers can manage things they don't understand and probably never will -- their role does not require domain expertise. I would argue that the hallmark of a poor manager is that they can't manage unless they are a domain expert, which they often use as a crutch to overcome lack of basic management skill. One of the greatest failure modes for software engineering managers with engineering backgrounds is the assumption that they can or will understand every part of the design they are managing. Not only is this unlikely in many cases but this delusion encourages them to dictate elements of engineering design that they are not intimately familiar with, invariably to the annoyance of the engineers that are tasked with doing the work and may have far more technical skill than the manager on the task at hand. For mundane software projects, an engineering manager with an engineering background may legitimately have the domain expertise, which is why it still gets things done despite being suboptimal for everyone.
This is really brought to light when doing complex, high-end software system engineering. In these cases my experience is that most experienced engineering managers with engineering backgrounds fail; because it is impossible to understand what your team does at a technical level, you can't lean on that. It is often difficult for very experienced engineers, now managers, to come to terms with the idea that someone working on "their" project has technical skills that they can't master or at least understand with a 15 minute explanation and a couple hours of research. Engineering managers, especially ones that were previously great engineers, must resist the instinct to technically master everything under their purview -- it doesn't scale. The advantage of non-engineering managers in these environments is that their management style doesn't rely on the assumption that they can technically master any part of the project, so they don't even try.
A big part of being a good engineering manager is letting go of what made you a great engineer. It isn't an easy thing to do.