engineering management

Questionable Advice: “My boss says we don’t need any engineering managers. Is he right?”

mipsytipsy, , , , , 18 Comments

I recently joined a startup to run an engineering org of about 40 engineers. My title is VP Engineering. However, I have been having lots of ongoing conflict with the CEO (a former engineer) around whether or not I am allowed to have or hire any dedicated engineering managers. Right now, the engineers are clustered into small teams of 3-4, each of which has a lead engineer — someone who leads the group, but whose primary responsibility is still writing code and shipping product.

I have headcount to hire more engineers in the coming year, but no managers. My boss says we are a startup and can’t afford such luxuries. It seems obvious to me that we need engineering managers, but to him, it seems just as obvious that managers are unnecessary overhead and that all hands should be on deck writing code at our stage.

I don’t know how to make that argument. It seems so obvious to me that I actually struggle to put it into words or make the case for why we should hire EMs. Help?

— Unnecessary Overhead(?!?)

Oh boy, there’s a lot to unpack here.

It is unsurprising to me that your CEO does not understand why managers exist, given that he does not seem to understand why organizational structures exist. šŸ™ˆ Why is he micromanaging how you are structuring your org or what roles you are allowed to fill? He hired you to do a job, and he’s not letting you do it. He can’t even explain why he isn’t letting you do it. This does not bode well.

But I do think it’s an interesting question. So let’s pretend he isn’t holding your ability to do your damn job hostage until you defend yourself to his satisfaction. šŸ˜’

I can think of two ways to make the case for engineering managers: one is rather complicated, from first principles, and the other very simple, but perhaps unsatisfying.

I personally have a … vigorous … knee-jerk response to authority; I hateĀ being told what to do. It’s only recently that I’ve found my way to an understanding of hierarchy that feels healthy and practical, and that was by looking at it through the lens of systems theory.

Why does hierarchy exist in organizations?

It makes sense that hierarchy comes with a lot of baggage. Many of us have had bad experience with managers ā€” indeed, entire organizations ā€” where hierarchy was used as a tool of oppression, where people rose up the leadership ranks by hoarding information and playing dominance games, and decisions got made by pulling rank.

Working at a place like that fucking sucks. Who wants to invest their creativity and life force into a place that feels like a Dilbert cartoon, knowing how little it will be valued or reciprocated, and that it will slowly but surely get crushed out of you?

But hierarchy is not intrinsically authoritarian. Hierarchy did not originate as a political structure that humans invented for controlling and dominating one another, it is in fact a property of self-organizing systems, and it emerges for the benefit of the subsystems. In fact, hierarchy is absolutely critical to the adaptability, resiliency, and scalability of complex systems.

Let’s start with few basic facts about systems, for anyone that may be unfamiliar.

Hierarchy is a property of self-organizing systems

A system is ā€œa network of interdependent components that work together to try to accomplish a common aimā€ (W. Edward Deming). A pile of sand is not a system, but a car is a system; if you take out its gas tank, the car cannot achieve its aim.

A subsystem is a collection of elements with a smaller aim inside a larger system. There can be many levels of subsystems that operate interdependently. The subsystems always work to support the needs of the larger system; if the subsystem instead optimizes for its own best interests, the whole system can fail (this is where the term “suboptimize” comes from šŸ˜„).

A system is self-organizing if it has the ability to make itself more complex, by diversifying, adapting, and improving itself. As systems self-organize and their complexity increases, they tend to generate hierarchy — an arrangement of systems and subsystems. In a stable, resilient and efficient system, subsystems can largely take care of themselves, regulate themselves, and serve the needs of the larger system, while the larger system coordinates between subsystems and helps them perform better.

Hierarchy minimizes the costs of coordination and reduces the amount of information that any given part of the system has to keep track of, preventing information overload. Information transfer and relationships within a subsystem are much more dense and have fewer delays than information transfer or relationships between subsystems.

(This should all sound pretty familiar to any software engineer. Modularization, amirite?? šŸ˜)

Applying this definition, we can say that a manager’s job is to coordinate between teams and help their team perform better.

The false binary of sociotechnical systems

You’ve probably heard this canard: “Engineers do the technical work, managers do the people work.” I hate it. ā˜ŗļø I think it misconstrues the fundamental nature of sociotechnical systems. The “socio” and “technical” of sociotechnical systems are not neatly separable, they are interwoven and interdependent. There is actually precious little that is purely technical work or purely people work; there is a metric shitload of glue work that draws upon both skill sets.

Consider a very partial list of tasks done by any functional engineering org, besides writing code:

  • Recruiting, networking, interviewing, training interviewers, synthesizing feedback, writing job descriptions and career ladders
  • Project management for each project or commitment, prioritizing backlog, managing stakeholders and resolving conflicts, estimating size and scope, running retrospectives
  • Running team meetings, having 1x1s, giving continuous growth feedback, writing reviews, representing the team’s needs
  • Architecture, code review, refactoring; capturing DORA and productivity metrics, managing alert volume to prevent burnout

A lot of this work can be done by engineers, and often is. Every company distributes the load somewhat differently. This is a good thing! You don’t WANT an org where this work is only done by managers. You want individual contributors to help co-create the org and have a stake in how it gets run. Almost all of this work would be done more effectively by someone with an engineering background.

So you can understand why someone might hesitate to spend valuable headcount on engineering managers. Why wouldn’t you want everyone in engineering to be writing and shipping code as their primary job? Isn’t that by definition the best way to maximize productivity?

Ehhh… šŸ˜‰

Engineering managers are a useful abstraction

In theory, you could make a list of all the tasks that need to be done to coordinate with other teams and have each item be picked up by a different person. In practice, this is impractical because then everybody would need to know about everything. One of the primary benefits of hierarchy, remember, is to reduce information overload. Intra-team communication should be high-bandwidth and fast, inter-team communication should be more sparse.

As the company scales, you can’t expect everybody to know everyone else; we need abstractions in order to function. A manager is the point of contact and representative for their team, and they serve as routers for important information.

I sometimes imagine managers as the nervous system of the company body, carrying around messages from one limb to another to coordinate actions. Centralizing many or most of these functions into one person lets you take advantage of specialization, as a manager builds relationships and context and improves at their role, and this massively reduces context switching for everyone else.

Manager calendars vs maker calendars

Engineering labor takes concentration and focus. Context switching is expensive, and too many interrupts can be fatal. Management labor consists of context switching every hour or so, and being available for interruptions throughout the day. These are two very different modes of being, headspaces, and calendar schedules, and do not coexist well.

In general, you want people to be able to spend most of their time working on things that contribute to the success of the outcomes they are directly responsible for. Engineers can only do so much glue work before their calendar turns into Swiss cheese and they can no longer deliver on their commitments. Since managers’ calendars are already Swiss cheese, it’s typically less disruptive for them to take on a larger share of glue labor.

It isn’t up to managers to do all the glue work, but it is a manager’s job to make sure that everything that needs to get done, does gets done. It is a manager’s job to try to line up every engineer with work that is interesting and challenging, but not overwhelming, and to ensure that unpleasant labor gets equitably distributed. It’s also a manager’s job to make sure that if we are asking someone to do a job, they are equipped with the resources they need to succeed at that job. Including time to focus.

Management is a tool for accountability

When you’re an engineer, you are responsible for the software you develop, deploy, and maintain. When you’re a manager, you are responsible for your team and the organization as a whole.

Management is one way of holding people accountable for specific outcomes (building teams with the right skills, relationships, and processes to make good decisions and build value for the company), and equipping them with the resources (budget, tools, headcount) to achieve those outcomes. If you aren’t making building the organization someone’s number one job, it won’t be anyone’s number one job, which means it probably won’t get done very well. And whose responsibility will that be, Mr. CEO?

There’s a real upper limit to what you can reasonably expect tech leads, or engineers, or anyone whose actual job is shipping software to do in their “spare time”. If you’re trying to hold your tech leads responsible for building healthy engineering teams, tools, and processes, you are asking them to do two calendarily incompatible jobs with only one calendar. The likeliest scenario is that they will focus on the outcomes they feel comfortable owning (the technical ones), while you pile up organizational debt in the background.

In natural hierarchies, we look up for purpose and down for function. That, in a nutshell, is the more complicated argument for why we need engineering managers.

Choose Boring technology Culture

The simpler argument is this: most engineering orgs have engineering managers. That’s the default. Lots of people much smarter than you or me have spent lots of time thinking and tinkering with org structures over the years, and this is what we’ve got.

As Dan McKinley famously said, we should “choose boring technology“. Boring doesn’t mean bad, it means the capabilities and failure conditions are well understood. You only ever get a few innovation tokens, so you should spend those wisely on core differentiators that could make or break your business. The same goes for culture. Do you really want to spend one of your tokens on org structure? Why??

For better or for worse, the hierarchical org structure is well understood. There are plenty of people on the job market who are proficient at managing or working with managers, and you can hire them. You can get training, coaching, or read a lot of self-help books. There are various management philosophies you can coalesce around or use to rule people out. On the other hand, the manager-free experiments I’m aware of (e.g. holacracy at Medium and GitHub, or “Choose Your Own Work” at Linden Lab) have all been quietly abandoned or outgrown. Not, in my experience, because leaders went mad for power, but due to chaos, lack of focus, and poor execution.

When there is no explicit structure or hierarchy, the result is not freedom and egalitarianism, it’s “informal, unacknowledged, and unaccountable leadership”, as famously detailed in “The Tyranny of Structureless“. In reality, sadly, these teams tend to be chaotic, fragile, and frustrating. I know! I’m pissed too! šŸ˜­

This argument doesn’t necessarily prove your CEO is wrong, but I should think his bar for proof is much higher than yours. “I don’t want any of my engineers to stop writing code” is not an argument. But I’m also feeling like I haven’t quite addressed the core question of productivity, so let’s pick that up again once more.

More lines of code != more productivity

To briefly recap: we were talking about an org with ~40 engineers, broken up into 10 small clusters of 3-4 engineers, each with a tech lead. Your CEO is arguing that you can’t afford to lose any velocity, which he thinks is what would happen if anyone stops writing code full time.

Maybe. But everything I have ever experienced leads me to believe that a fewer number of larger teams, each helmed by an experienced engineering manager, should way outperform this gaggle of tiny groups. It’s not even close. And they can do so in a way that’s more efficient, sustainable, and humane than this scrappy death march.

And systems thinking shows us why! With fewer groups, but larger ones, you have less overall management overhead, and much less of the slow and costly intra-group coordination. You unlock rich, dense knowledge transfer within groups, which gives you more shared coverage of the surface area. With 7-9 engineers per group you can build a real on call rotation, which means fewer heroics and less burnout. The coordination that you do need to do can be more strategic, less tactical, and much more forward-looking.

Would five big teams ship as many lines of code as 10 small teams, even if five engineers become managers and stop writing code? Probably, but who cares? Your customers give zero fucks how many lines of code you write. They care about whether you are building the right things and solving problems that matter to them. What matters is moving the business forward, not churning out code. Don’t forget, the act of churning out code creates costs and externalities in and of itself.

What defines your velocity is that you spend your time on the right things. Learning to make good decisions about what to build is something every organization has to work out for itself, and it is always an ongoing work in progress. Engineering managers don’t do all the work or make all the decisions, but they are absolutely fucking vital, in my experience, to ensuring that work happens and is done well. As I wrote in my last piece, engineering managers are the embodiment of the feedback loops that systems use to learn and improve.

Are managers ever unnecessary overhead?

Sure, absolutely. Management is about coordinating between teams and helping teams run more optimally, so anything that decreases your need for coordination also decreases your need for management. If you are a small company, or if you have really senior folks who are used to working together, you need a lot less coordination. The next most relevant factor is probably the rate of change; if you’re growing fast or have a lot of turnover, or if there’s a lot of time pressure or frequent shifts in strategy, your need for managers goes up. But there are plenty of smaller orgs out there that are doing just fine without a lot of formal management.

Look, I’m not a fan of the word “overhead”, because a) it’s kind of rude and b) people who call managers “overhead” are typically people who disrespect or do not value the craft of management.

But management is, in fact, overhead. šŸ˜… So is a lot of other glue work! By which I mean the work is important, but does not itself move the business forward; we should do as much of it as absolutely necessary and no more. The nature of glue work is such that it too-easily expands to consume all available time and space (and then some). Constraints are good. Feeling a bit underresourced is good, and should be the norm. It is incredibly easy for management to get a bit bloated, and managers can be very loath to acknowledge this, because it’s not like they ever feel any less stressed or stretched.[*]

Management is also very much like operations work in that when it’s being done well, it’s invisible. Evaluating managers can be very hard, especially in the near term, and making decisions about when it’s time to create or pay down organizational debt is a whole nother ball of wax, and way outside the scope of this post.

But yes, managers can absolutely be unnecessary overhead.

However, if you have 40 engineers all reporting to one VP, and nobody else whose number one job is the outcomes related to people, teams and org, I feel pretty safe in saying this is not a risk for you at this time.

<3 charity

[*] In fact, the reverse can be true; bloated management can create MORE work for managers, and they may counterintuitively feel LESS stretched or stressed with a leaner org chart. Bureaucracies do tend to pick up a momentum all their own. Especially when management gets all wrapped up in promotions and egos. Which is yet another good reason to ensure that management is not a promotion or a form of domination.

 

Questionable Advice: “My boss says we don’t need any engineering managers. Is he right?”

Becoming An Engineering Manager Can Make You Better At Life And Relationships

mipsytipsy, , , , , 31 Comments

Original title: “Why Should You (Or Anyone) Become An Engineering Manager?”

The first piece I ever wrote about engineering management, The Engineer/Manager Pendulum, was written as a love letter to a friend of mine who was unhappy at work. He was an engineering director at a large and fast-growing startup, where he had substantially built out the entire infrastructure org, but he really missed being an engineer and building things. He wasnā€™t getting a lot of satisfaction out of his work, and he felt like there were other people who might relish the challenge and do it better than he could.

At the same time, it felt like a lot to walk away from! He had spent years building up not only the teams, but also his influence and reputation. He had grown accustomed to being in the room where decisions get made, and didnā€™t want to give that up or take a big step back in his career. He agonized over this for a long time (and I listened over many whiskeys). šŸ™‚

To me it seemed obvious that his power and influence would only increase if he went back to engineering. You bring your credibility and your relationships along with you, and enthusiasm is contagious. So I wrote the piece with him in mind, but it definitely struck a nerve; it is still the most-read piece I have ever written.

That was in 2017. I’ve written a lot over the years since then about teams and management. For a long time, everything I wrote seemed to come out with a pretty noticeable bias against management, towards engineering:

I go back and read some of those pieces now, and the pervasive anti-manager slant actually makes me a bit uncomfortable, because the environment has changed quite a lot since then.

Miserable managers have miserable reports

When I started writing about engineering management, it seemed like there were a lot of unhappy, resentful, poorly trained managers, lots of whom would prefer to be writing code. Most people made the choice to switch to management for reasons that had nothing to do with the work itself.

  • Becoming a manager was seen as a promotion
  • It was the only form of career progression available at many places
  • Managers made a lot more money
  • It was the only way to get a seat at the table, or be in the loop
  • They were tired of taking orders from someone else

But a lot has changed. The emergence of staff+ engineering has been huge (two new books published in the last five years, and at least one conference!). The industry has broadly coalesced around engineering levels and career progression; a parallel technical leadership track is now commonplace.

Weā€™ve become more aware of how fragile command-and-control systems are, and that you want to engage peopleā€™s agency and critical thinking skills. You want them to feel ownership over their labor. You can’t build great software on autopilot, or by picking up jira tasks. Our systems are becoming so complex that you need people to be emotionally and mentally engaged, curious, and continuously learning and improving, both as individuals and as teams.

At the same time, our expectations for managers have gone up dramatically.Ā We’ve become more aware of the damage done by shoddy managers, and we increasingly expect managers to be empathetic, supportive, as well as deeply technical. All of this has made the job of engineering manager more challenging.

Ambitious engineers had already begun to drift away from management and towards the role of staff or principal engineer. And then came the pandemic, which caused managers (poorly supported, overwhelmed, squeezed between unrealistic expectations on both sides) to flee the profession in droves.

It’s getting harder to find people who are willing to be managers. On the one hand, it is fucking fantastic that people arenā€™t being driven into management out of greed, rage, or a lust for power. It is WONDERFUL that people are finding engineering roles where they have autonomy, ownership, and career progression, and where they are recognized and rewarded for their contributions.

On the other hand, engineering managers are incredibly important and we need them. Desperately.

Good engineering managers are force multipliers

A team with a good engineering manager will build circles around a team without one. The larger or more complex the org or the product, and the faster you want to move, the more true this is. Everybody understands the emotional component, that it feels nice to have a competent manager you trust. But these arenā€™t just squishy feels. This shit translates directly into velocity and quality. The biggest obstacles to engineering productivity are not writing lines of code too slowly or not working long hours, they are:

  • Working on the wrong thing
  • Getting bogged down in arguments, or being endlessly indecisive
  • Waiting on other teams to do their work, waiting on code review
  • Ramping new engineers, or trying to support unfamiliar code
  • When people are upset, distracted, or unmotivated
  • Unfinished migrations, migrations in flight, or having to support multiple systems indefinitely
  • When production systems are poorly understood and opaque, quality suffers, and firefighting skyrockets
  • Terrible processes, tools, or calendars that don’t support focus time
  • People who refuse to talk to each other
  • Letting bad hires and chronic underperformers stick around indefinitely

Engineers are responsible for delivering products and outcomes, but managers are responsible for the systems and structural support that enables this to happen.

Managers donā€™t make all the decisions, but they do ensure the decisions get made. They make sure that workstreams are are staffed and resourced sufficiently, that engineers are trained and improving at their craft. They pay attention to the contracts and commitments you have made with other teams, companies or orgs. They advocate for your needs at all levels of the organization. They connect dots and nudge and suggest ideas or solutions, they connect strategy with execution.

Breaking down a complex business problem into a software project that involves the collaboration of multiple teams, and ensuring that every single contributor has work to do that is challenging and pushes their boundaries while not being overwhelming or impossible… is really fucking hard. Even the best leaders don’t get it right every time.

In systems theory, hierarchy emerges for the benefit of the subsystems. Hierarchy exists to coordinate between the subsystems and help them improve their function; it is how systems create resiliency to unknown stressors. Which means that managers are, in a very real way, the embodiment of the feedback loops and meta loops that a system depends on to align itself and all of its parts around a goal, and for the system itself to improve over time.

For some people, that is motivation enough to try being a manager. But not for all (and thatā€™s okay!!). What are some other reasons for going into management?

Why should you (or anyone) be a manager?

I can think of a few good reasons off the top of my head, likeā€¦

  • It gets you closer to how the business operates, and gives you a view into how and why decisions get made that translate eventually into the work you do as an engineer
  • Which makes the work feel more meaningful and less arbitrary, I think. It connects you to the real value you are creating in the world.
  • Many people reach a point where they feel a gravitational pull towards mentorship. It’s almost like a biological imperative to replicate yourself and pass on what you have learned to the next generation.
  • Many people also get to a point where they develop strong convictions about what not to do as a manager. They may feel compelled to use what they’ve learned to build happy teams and propagate better practices through the industry
  • One way to develop a great staff engineer is to take a great senior engineer and put them through 2-3 years of management experience.

But the main reason I would encourage you to try engineering management is a reason that Iā€™m not sure Iā€™ve ever heard someone articulate up front, which is thatā€¦it can make you better at life and relationships, in a huge and meaningful way.

Work is always about two things: what you put out into the world, and who you become while doing it.

I want to stop short of proclaiming that ā€œbeing a manager will make you a better person!ā€ — because skills are skills, and they can be used for good or ill. But it can.

Itā€™s a lot like choosing to become a parent. You donā€™t decide to have kids because it sounds like a hoot (I hope); you go into it knowing it will be hard work, but meaningful work. Itā€™s a way of processing and passing on the experiences that have shaped you and who you are. You also take up the mantle understanding that this will change you ā€” it changes who you are as a person, and the relationships you have with others.

From the outside, management looks like making decisions and calling the shots. From the inside, management looks more like becoming intimately acquainted with your own limitations and motivations and those of others, plus a lot of systems thinking.

Yes, management absolutely draws on higher-level skills like strategy and planning, writing reviews, mediating conflict, designing org charts, etc. But being a good manager ā€” showing up for other people and supporting them consistently, day after day ā€” rests on a bedrock of some much more foundational skills.

The kind of skills you learn in therapy, not in classes

Self-regulation. Can you take care of yourself consistently ā€” sleep, eat, leave the house, socialize, balance your moods, moderate your impulses? As an engineer, you can run your tank dry on occasion, but as a manager, thatā€™s malpractice. You always need to have fuel left in the tank, because you donā€™t know when it will be called upon.

Self-awareness. Identifying your feelings in the heat of the moment, unpacking where they came from, and deciding how to act on them. Itā€™s not about clamping down on your feelings and denying you have them. Itā€™s definitely not about making your feelings into other peopleā€™s problems, or letting your reactions create even bigger problems for your future self. Itā€™s about acting in ways that are fueled by your authentic emotional responses, but not ruled by them.

Understanding other people. You learn to read people and their reactions, starting with your direct reports. You build up a mental model for what motivates someone, what moves them, what bothers them, and what will be extremely challenging for them. You must develop a complex topographical map of how much you can trust each personā€™s judgment, on which aspect, in any given situation.

Setting good boundaries. Where is the line between supporting someone, advocating for them, encouraging them, pushing them ā€¦ but not propping them up at all costs, or taking responsibility for their success? How is the manager/report relationship different from the coworker relationship, or the friend relationship? How do you navigate the times when you have to hold someone accountable because their work is falling short?

Sensitivity to power dynamics. Do people treat you differently as a manager than they did as a peer? Are there things that used to be okay for you to say or do that now come across as inappropriate or coercive? How does interacting with your reports inform the way you interact with your own manager, or how you understand what they say?

Hard conversations. Telling people things that you know they donā€™t want to hear, or things that will make them feel afraid, angry, or upset; and then sitting with their reactions, resisting the urge to take it all back and make everything okay.

The art of being on the same side. When youā€™re giving someone feedback, especially constructive feedback, itā€™s easy to trigger a defensive response. Itā€™s SO easy for people to feel like you are judging them or criticizing them. But the dynamic you want to foster is one where you are both side by side, shoulder to shoulder, facing the same way, working together. You are giving them feedback because you care; feedback that could help them be even better, if they choose to accept it. You are on their side. They always have agency.

Did you learn these skills growing up? I sure as hell did not.

I grew up in a family that was very nice. It was very kind and loving and peaceful, but we did not tell each other hard things. When I went off to college and started dating, I had no idea how to speak up when something bothered me. There were sentences that lingered on the tip of my tongue for years but were never spoken out loud, over the ebb and fall of entire relationships. And if somebody raises their voice to me in anger, to this day, I crumble.

I also came painfully late to developing a so-called growth mindset. This is super common among ā€œsmart kidsā€, who get so used to perfect scores and praise for high achievements that any feedback or critique feels like failure…and failure feels like the end of the world.

It was only after I became a manager that I began to consciously practice skills like giving feedback, or receiving constructive criticism, or initiating hard conversations. I had to. But once I did, I started getting better.

Turns out, work is actually kind of an ideal sandbox for life skills, because the social contract is more explicit. These are structured relationships, with rules and conventions and expectations, and your purpose for coming together is clear: to succeed at business, to finish a project, to pull a paycheck. Even the element of depersonalization can be useful: itā€™s not you-you, itā€™s the professional version of you, performing a professional role. The stakes are lower than they would be with your mother, your partner, or your child.

You donā€™t have to be a manager to build these skills, of course. But itā€™s a great opportunity to do so! And there are tools ā€” books and classes, mentors and review cycles. You can ask for feedback from others. Growth and development is expected in this role.

People skills are persistent

The last thing I will say is this ā€” technical skills do decay and become obsolete, particularly language fluency, but people skills do not. Once you have built these muscles, you will carry them with you for life. They will enhance your ability to connect with people and build trust, to listen perceptively and communicate clearly, in both personal and professional relationships.

Whatever you decide to do with your life, these skills increase your optionality and make you more effective.

And that is the reason I think you should consider being an engineering manager. Like I said, I’ve never heard someone cite this as their reason for wanting to become a manager. But if you ask managers why they do it five or ten years later, you hear a version of this over and over again.

One cautionary note

As an engineer, you can work for a company whose leadership team you donā€™t particularly respect, whose product you donā€™t especially love, or whose goals you arenā€™t super aligned with, and it can be ā€œokay.ā€ Not terrific, but not terrible.

As a manager, you canā€™t. Or you shouldnā€™t. The conflicts will eat you up inside and/or prevent you from doing excellent work.

Your job consists of representing the leadership team and their decisions, pulling people into alignment with the companyā€™s goals, and thinking about how to better achieve the mission. As far as your team goes, you are the face of The Man. If you canā€™t do that, you canā€™t do your job. You donā€™t get to stand apart from the org and throw rocks, e.g. ā€œthey told me I have to tell you this, but I donā€™t agree with itā€. That does nothing but undermine your own position and the companyā€™s. If you’re going to be a manager, choose your company wisely.

charity

P.S. My friend (from the start of the article) went back to being an engineer, despite his trepidation, and never regretted it once. His career has been up and to the right ever since; he went on to start a company. The skills he built as a manager were a huge boost to an already stellar career. šŸ“ˆ

 

Becoming An Engineering Manager Can Make You Better At Life And Relationships