I thought the same way in my first engineering management position. I worked really hard to build the team I always wanted to work on. We trusted each other, worked well together, performed at the top of teams in the company, it was great.
All that trust was destroyed overnight the first time I had to take a directive from executive management that required I put the interests of the business over the team. Basically, I was forced to lie and manipulate about the state of the company to keep the team in place until an acquisition deal could close. Because of my role I was involved in the details such that I knew several projects would be canceled and layoffs would be done.
After that, my team completely turned against me and called me a hypocrite. I couldn’t blame them. A few even speculated I was putting on some kind of show for them and playing some epic long game to win their trust just so I could use it to benefit myself. My best engineers left, and performance of the team subsequently dropped. Executive management blamed me for that too.
Basically, engineering management is a no win game and not worth the stress if you’re a good person. You will eventually, despite all efforts, work your way into an “us vs. them” situation. If you’ve previously preached trust and empathy and transparency or whatever feel good buzzwords dejour you’ll also look like a liar and hypocrite as I was. Anyone who has been in the role for a sufficiently long period will experience something similar to what I’m talking about. It’s only a matter of time.
After what happened, I could no longer stomach putting on another trust-fall-esque dog and pony show. Once you’ve been shown the ugly truths, it becomes hard to keep repeating the same rhetoric that you did before that oddly would make you into exactly the thing you tried so hard not to become in the first place. It really test your own mental image of yourself.
These days I try to project a more realistic attitude. I tell people I’ll do everything I can to be as transparent and open with everything but at the end of the day we’re still working for a company and business where the future is completely unpredictable and it’s in fact a lie to say there are no information asymmetry and cognitive dissonance between management and IC engineers.
Having a well run trusting team isn’t enough and can even make it more likely for one of these situations to occur.
At the end of the day, your direct reports view YOU as the company in a lot of ways. You are their main interface to the rest of the machine.
Just yesterday I had my boss say roughly "don't tell anyone I told you this, but ..." and proceeded to explain what's going on "upstairs".
If you're not willing to take a risk and trust them then you're not trustworthy and whinging on a forum about how unfair people are for not understanding your reasons for lying to them means you didn't learn anything from the exercise.
If I ask a question and my boss tells me "I can't talk about that because X, Y, or Z", I'm fine with it. We're all adults here, we all understand there can't be complete transparency. But you lied to them by omission about things that can affect their employment status. They don't trust you because you're not trustworthy.
Yup. I preface a statement about once a week by saying “there’s a difference between ‘I can’t say’ and ‘I don’t know.’ In this case, …”
It’s been useful. It helps to communicate without breaking bonds of confidentiality or trust.
It also helps people from reading too much into an off the cuff “I dunno” which is literally true. I do not in fact have knowledge of what you’re asking about. Maybe I should or shouldn’t but I can tell you I don’t know.
This is hollow advice. Your job as an engineering manager is to maintain the integrity of the team and deliver business results. You can’t have it both ways. You can’t preach trust and transparency if your definition is selective. By definition those things require authenticity and completeness.
Would you trust or accept as an answer someone who tells you “I can’t say” when asked a very direct question “Is my job safe? Should I start looking for another job?”
Especially when you’ve been ordered (and let’s face it, executives give orders, not suggestions when it comes to this stuff). They expect your loyalty is to them and they also have trust in you that will be violated if you don’t follow their “guidance”.
So what are your choices as an EM? No good ones, besides the obvious of don’t put yourself in that position if you like to think of yourself as a good person.
There are always going to be people on the team for whom the manager will never be good enough. This does not mean most reasonable people run around with such a negative view of everything.
Which, btw, is what I'm getting from your post. That you're one of those people.
* If you tell the team to keep their trust, you loose management's trust. The good thing is you can't be put in this position if management won't tell you. The bad thing is you won't have a job.
* If you don't tell the team, you loose their trust while keeping management's trust.
At the end of the day, most managers are limited by corporate context they work in. They can only be as trustworthy as they're allowed to be.
> They can only be as trustworthy as they're allowed to be.
This may be true, but it still means they're untrustworthy. We all are responsible for our own actions. Behaving in an untrustworthy fashion says something important about a person even if (or especially if) they're behaving that way to save their own skin.
But it sounds like you actually did lie to them, perhaps more than once. That's the problem.
I've been through acquisitions, I've been on teams where 90% of the team was culled and the manager knew about it months and months in advance. In none of those situations did I feel betrayal or like the manager was a liar. Do you know why? Because they never lied. Nothing in the article that I read indicates you need to tell your team everything you know, or that you need to paint a rosy red picture of things when that may not be the case.
Sorry but you don't get a pass for that because "the company told me to". You can manage through tough circumstances with integrity, or you can resign.
Otherwise it shows the priority is about you and your position, not your employees.
(Yes it does not always lead to monetary success, hence why I'm still working after 20 years..)
I hear you. You have honestly identified that the information asymmetry causes trust to be destroyed. It causes cognitive dissonance among ICs, leading to all problems.
> These days I try to project a more realistic attitude. I tell people I’ll do everything I can to be as transparent and open with everything but at the end of the day we’re still working for a company and business where the future is completely unpredictable and it’s in fact a lie to say there are no information asymmetry and cognitive dissonance between management and IC engineers. Having a well run trusting team isn’t enough and can even make it more likely for one of these situations to occur.
------
This is in fact, a good way to build trust. But there's more to do in terms of being transparent and honest.
I'll give you an example. A lot of companies work like Amazon where they stack rank and pip people constantly. It causes a lot of grief among ICs. The low level EM really doesn't have a choice but to implement executive policies.
So are EMs just hapless? No. They can do a few things. When the pip/focus arrives, transparently and honestly say that you were targeted - from above. Let the blame flow upwards. Let the blame flow towards the people who are to be blamed.
No IC realistically trusts corporations any longer. But By letting the blame flow upwards and being transparent about what's cooking behind the scenes, you ARE building trust.
Your early and consistent transparency could be the way a father starts looking for another job early to feed their children. Your early and consistent transparency is how a student with a loan can prevent themselves from falling apart. It can help someone with complex immigration situations figure a way out before shit hits the wall. It can help a pregnant woman plan something towards pregnancy (especially health insurance).
Just be transparent about corporate nonsense and let the blame flow upwards. That is trustworthy.
> Basically, engineering management is a no win game and not worth the stress if you’re a good person
This is what soured me on being an EM.
I stumbled into the role over time and was very much team-focused over company-focused. Over time I realized that's not tenable. At the end of the day your first team (borrowing a term from 5 Dysfunctions of a Team [1]) needs to be such that you're more beholding to the company than your reports.
For me I couldn't handle the inner turmoil & stress that created. The times where one can't both do right by their reports *and* the business ate at me.
people are not stupid- they know a business needs to make money. middle managers who tries to hide this from their team, even with the best intention (ie, to "shield" them from the realities) are only fooling themselves and in the end will always look like hypocrites to their team, while also taking the blame from higher ups. there's no winning.
Most replies missing the forest for the trees in this anecdote by focusing on a lack of mutual trust.
Management is fundamentally the art of aligning your team’s motivations toward the company’s benefit. Inevitably, those things will be irreconcilable and as a manager, it’s your obligation to do what’s in the company’s interest.
If you can’t stomach that, you will be happier avoiding the manager track.
If anybody blamed me for not being fully transparent about such things, I would tell them "welcome to earth." I remember the project manager at a past company I worked for said "In here, it's all about the end user. Our lives don't matter." He was right. The markets don't give a crap about you or your life in the same way it doesn't give a crap about the life of your competitors which you put out of business.
Also, omission of facts is not lying. There is no obligation for you to keep them informed about everything that's happening in the business. They can read their employment contract.
Very cold and insensitive management style in my opinion.
If a project I was working on for multiple years and I believed in was shut down and my manager told me “welcome to earth” and “our lives don’t matter” I would one hundred percent leave.
Yes, the markets are cold and ruthless but it doesn’t mean you have to be.
> Lying by omission, also known as a continuing misrepresentation or quote mining, occurs when an important fact is left out in order to foster a misconception. Lying by omission includes the failure to correct pre-existing misconceptions. For example, when the seller of a car declares it has been serviced regularly, but does not mention that a fault was reported during the last service, the seller lies by omission. It may be compared to dissimulation. An omission is when a person tells most of the truth, but leaves out a few key facts that therefore, completely obscures the truth.
> The markets don't give a crap about you or your life in the same way it doesn't give a crap about the life of your competitors which you put out of business.
It's not just markets. You also don't care about the employees' psychological safety of, say, the toothpaste manufacturer you buy the toothpaste of. You just want toothpaste.
While I personally think it's important to have high integrity, and to work in a company where this is not undermined, ultimately it's about whether or not your company is doing something valuable enough for others to pay for. That's why your salary comes in every month.
At my previous company I had an amazing team that was very intrinsically motivated, they needed me to generally protect them from politics, participate in planning, and stay out of the way. They delivered wonderful results and saved our employer a lot of money. I would have considered myself “an engineer focused leader”.
New spot has challenged my identity a lot. I was expecting to come in and essentially do the same and it turned out the culture and people are almost completely different. My team needs a lot of performance management and cajoling to stay focused and deliver. For the first year I tried to be understanding, lead gently, and avoid awkward conversations, but I suspect my team was savvy to this and has weaponize my empathy a bit. I am now stuck in an awkward situation where I need essentially change who I am to the team and I don’t totally know how to do that gracefully.
This is 100% a problem of my own making. I am still figuring out how far I want to personally adopt a more “company focused vs person focused” mindset.
I've worked as an IC on both highly productive teams, and completely stagnant teams. All of the productive teams were lightly managed, while the stagnant teams were very heavily managed. Some developers are just not ever going to be productive no matter what you do. However, many will respond well if they sense a positive trajectory - less stress, enough autonomy to tackle some tech debt or play with idea they have. Daily standups, sprint deadlines, etc... are counter productive IMO. They offer a sense of control to management, while simultaneously making your team less productive in the long run.
Thank you for the response. I really want to avoid formal stuff like sprints and stand ups if at all possible. As a former engineer, I agree that it burdens ICs needlessly and would take up a lot of my time to manage. I am struggling with finding the balance of accountability and autonomy and how to meaningfully track that.
My current team is a hulk assembled from a few previously broken teams. Essentially no one is doing the work they were hired for and there is fairly intense resistance from other areas of the business when we try to make change.
Lesson here is to be diligent about finding out why the team you will managing exists and a bit of how it came to be during the interview process.
Thanks for the response, it gave me a grim chuckle.
I feel like taking the servant leader approach is also a trap for your own development. And it shouldn't be like that. It kind of defeats the purpose of taking the role unless you are a masochist (I sometimes am...)
But it is hard of course. You also dont want to become pointy haired boss.
I don't know why it is but it is. Every company now has a mission/vision/culture statement touting trust, respect, inclusivity, innovation, ethics, and similar flapdoodle (dis)embodied by Corporate Memphis grotesqueries. In fact, it is getting harder to find product information on company websites because home page real-estate is liberally sprinkled with this stuff in between some diffuse product blurbage.
There may be people within the firms that embody some or most of those things. A fraction of those may be low-level managers. Anyone in a position of power achieves that power by doing the exact opposite of the published boilerplate.
Touting trust by the company is PR. Building trust by the team is daily practice as basic and real and important as the rest of the actual work. I understand your cynicism regarding the often empty words of PR statements.
>On large teams, it's about leveraging expertise and building consensus.
Is it though? This is touted fairly often, but rarely often does it actually make effective teams or organizations.
It does make for great career advancement though! Which unfortunately being great at advancing your career doesn't make you a great engineering manager.
Why? Isn't the more important thing making the correct decision, and choosing the correct direction, and executing it correctly? You don't need large teams for that.
I have often found companies go through a cycle. There's a building the "people pyramid" cycle, then there is a distillation that happens when companies actually need to execute in a competitive environment.
That presupposes there is one canonical correct decision.
Most decisions are far from that. There are multiple different proposals, with different set of trade-offs. Choosing the right trade-offs requires broad input with many different perspectives. Which means a large number of people who have now presented something that's the right answer from their perspective - getting folks to see each others points, and agreeing on what the best outcome is requires a good chunk of consensus building.
> You don't need large teams for that.
You are literally replying to a post that said "the bigger the team is, the more important [...]", left out the first part about team size and then postulate that you don't need large teams?
Yes, consensus building is a much less important thing with a small tightly knit team of a few people. Once you're past a dozen or so people, it's quite important. Add a couple partner teams of the same size, and you'll fail without it. Spectacularly.
>left out the first part about team size and then postulate that you don't need large teams?
If you have to undergo an activity so large you think that "consensus" building is first and foremost the most important thing then that team is now a detriment to the overall prosperity of the organization.
That is to say, consensus building is an organic part of smaller teams, not a notable activity.
If you need leadership or specific people to do this, the team is too large for any real "serious" productive effort. And I don't mean technically.
And before people say "well maybe you just haven't...", no I guarantee you have, but more importantly I am far from the first person to say this. Many people including those we would consider "fathers" of our industry have stated this ad nauseam.
Please, do show me a place that runs, say, a 100+ person team where there isn't a significant amount of consensus building.
And if you believe all useful activity can be done by less than 100 people, you might want to acquaint yourself with actual team sizes for most major software. Yes, small and valuable teams exist, but a lot of stuff requires large teams.
Even a simple chat app, praised for being extremely lean, ran on a 35 person team (WhatsApp). Linux is running at ~1000 contributors, with a lot of coordination via lkml and side channels. It has a management structure, via Linus + lieutenants. OpenAI has ~500 folks. (I'm happy to hear counterexamples here - just because I don't know about them doesn't mean they don't exist)
Communication & consensus overhead is real. Hierarchical structures evolve repeatedly for exactly that reason. The attempts at non-hierarchy are merely hiding that complexity - either via large losses (the OSS model where PRs just get thrown away if the maintainers don't agree, and that work is 'lost') or via informal groups. (Good reading: The Tyranny of Structurelessness)
(BTW: Would love to see quotes from those "fathers")
What you _can_ achieve in small teams is technical breakthroughs, and first working models. There's a reason skunkworks efforts exist. And even there, it's worth noting that the original SkunkWorks effort (XP-80) succeeded because it had a very strong manager, not because they just had a bunch of people in a room.
What you can't do with a small team is productionize for a large audience from there.
The biggest problem with the post you responded to is this idea that decisions can't be revisited, that they're set in stone. Or that they're all equal. Neither is true.
_sometimes_ a decision needs to take longer because the ramifications are broad and recovering from a poor decision is difficult. this is rare, but does happen.
More importantly, if your company is struggling in this manner on a regular basis, you're working in a top-down authoritarian manner and are not giving the teams themselves (the boots on the ground, aka the executors) enough autonomy.
There are solutions to these problems but they generally involve not enjoying the authoritarian nature of both company hierarchies and software in general.
Do you think you're smarter than the rest of the team combined? You can't make the "correct" decision by yourself. And then everything gets more complicated.
There was a proposal for a new branching strategy some 3-4 months ago. The team is still debating things.
Not only that, but one of the developers specifically asked the manager to make a decision, he punted, insisting that the team should be the one making the decision.
What makes it worse is that the decisions themselves don't actually matter, we just need a decision made and then communication on what that decision is. Something I expected to happen over 1-2 weeks has taken almost half a year now.
"executing it correctly" requires consensus on the goals and direction. Maybe I'm reading too much between the lines, but you seem to think that building consensus implies a voting process with a unanimous outcome. That's not the case, especially not in hierarchical organizations.
The root of consensus is the word consent: it's about buy-in, not about unanimous agreement. It is customary to choose the direction with a small team -- but you still need the rest of the people to understand those decisions and why they were made. If people don't understand the context of the work they're doing, it's impossible for them to make the correct judgement calls for the tasks they're working on.
To get people in larger teams to work together efficiently, you need either consensus building or micro-management. I know which one I prefer.
> "executing it correctly" requires consensus on the goals and direction. Maybe I'm reading too much between the lines, but you seem to think that building consensus implies a voting process with a unanimous outcome. That's not the case, especially not in hierarchical organizations.
you're the one who is mistaken here, consensus is absolutely about getting everyone to agree to something. If you're not doing that then it's bog standard communication of decisions made.
Which is important, but is not "building consensus". Lets be accurate in our wording.
At my current company I've had money thrown at me hand over fist and a large part of the reason for that is I don't build consensus, I DO instead, which means every project I've been a part of has come in on-time with the features requested (with compromises of course). Apparently they've had a distinct inability to deliver much before I came along.
"Consensus building" is the same as saying politicking in meetings. That doesn't mean I haven't built relationships with people, but it goes without saying that no one in a larger company is a 1 man band.
But when people call out consensus building specifically they're not talking about the usual coordination that has to happen, they're talking about consensus being the predominant activity and you can't get shit down that way. It's ok if not everyone gets their say in things.
> On large teams, it's about leveraging expertise and building consensus.
I think the opposite is true, it's about leading people, not getting everyone to compromise.
You share initial vision, take feedback, then share final vision and tell people "this is where we are going". Inevitably, some people will dislike it or not share in the vision. You meet with them and try to incorporate ideas that help achieve goals. If not, you help find them a new role that (hopefully) they'll enjoy.
IMO as a leader of any scale, your job is to mentor (or set up mentorship), set goals, layout reasons and help people feel pride in the accomplishment. It's not to hand hold or build consensus around the vision. Everything else is tactical and can be negotiated to an extent (timelines, implementations, etc), but should be largely delegated.
It depends on the team. If you have a team with experienced people, they may well have useful input to give on changing the direction of things, and facilitating consensus is more important IMO.
And yet every part about most people’s ascendency up the management ladder reinforces that it is. The pay usually goes up. An increase in attention from the outside goes up. You are held responsible. The process usually is mired in some show of “selection” where you the individual are rendered “distinct” from your peers (of course, there’s a dark pattern that as the least competent/influential member of the ranks at hand, you are put in a place where you do less damage to the actual “value creation” pipeline). It’s not like you and your peers drew straws, and you took the noble sacrificial road of collegiate duty, taking the low road so others could remain on the high. Even if you strive for some form of equanimity in the greater effort, self titling yourself “manatary” or “secrager”, those that work for you, or you work for, or whatever, will treat you differently than peers, practicing various forms of signaling to advance their own status.
Read the article. Nice principles. But seemed pretty idealistic/naive when refracted off of my experience in most corporate cultures.
I think it's true that "it's not about you" - but management is also not some kind of noble sacrifice either. The article is saying that being authentic with your team about your own strengths and weaknesses and focusing on their needs will lead to better outcomes. Pretending you're equals when there's a clear power dynamic at play isn't being authentic.
> Pretending you're equals when there's a clear power dynamic at play isn't being authentic.
I think this is a good summary. It's like in a classroom when teachers don't behave as authority figures, but then get frustrated when some kids don't treat them like one. You need to expect the outcomes your leadership style is bound to attract.
I can't say I've ever had an EM who made anything simpler or easier. I have had team leads and staff engineers who did. Maybe I'm just missing out. @vrosas' comment about localized HR reps is apt--there for the company, not you, and that's not great.
At larger orgs I've found engineering managers to basically just be localized HR representatives - there to handle disputes and escalate as needed. They also sometimes act as mediocre project/product managers as needed. Anyone who had any talent as an engineer was... still an engineer.
In my industry, I've found that people with serious technical chops can figure things out and get things done in new areas, even as managers.
The problem is with those who get onto the management track double-quick and replace any technical books they have with rah-rah management theories. They seek out management roles, get them, and then depend on others to do the hard thinking and tough trades. It is a point of pride to them to say, "I have people that do that for me" even if they have done Masters or Doctorate level technical work at some point.
On the other hand, there's also the impact you can do higher up is much bigger. To answer on another comment, at this point the ideas don't have to be yours anymore, and it's good so. But your experience and your position will be able to filter them, merge or spread, thus impacting the entire multi-team environment in a positive way (of course, otherwise why are you there at all). And yes others will actually do it, but you should get and keep the good understanding on the what and why for every one of those pieces. Maybe that's more "architect" than "manager" though, so possibly I'm fighting the wrong debate here...
All that trust was destroyed overnight the first time I had to take a directive from executive management that required I put the interests of the business over the team. Basically, I was forced to lie and manipulate about the state of the company to keep the team in place until an acquisition deal could close. Because of my role I was involved in the details such that I knew several projects would be canceled and layoffs would be done.
After that, my team completely turned against me and called me a hypocrite. I couldn’t blame them. A few even speculated I was putting on some kind of show for them and playing some epic long game to win their trust just so I could use it to benefit myself. My best engineers left, and performance of the team subsequently dropped. Executive management blamed me for that too.
Basically, engineering management is a no win game and not worth the stress if you’re a good person. You will eventually, despite all efforts, work your way into an “us vs. them” situation. If you’ve previously preached trust and empathy and transparency or whatever feel good buzzwords dejour you’ll also look like a liar and hypocrite as I was. Anyone who has been in the role for a sufficiently long period will experience something similar to what I’m talking about. It’s only a matter of time.
After what happened, I could no longer stomach putting on another trust-fall-esque dog and pony show. Once you’ve been shown the ugly truths, it becomes hard to keep repeating the same rhetoric that you did before that oddly would make you into exactly the thing you tried so hard not to become in the first place. It really test your own mental image of yourself.
These days I try to project a more realistic attitude. I tell people I’ll do everything I can to be as transparent and open with everything but at the end of the day we’re still working for a company and business where the future is completely unpredictable and it’s in fact a lie to say there are no information asymmetry and cognitive dissonance between management and IC engineers. Having a well run trusting team isn’t enough and can even make it more likely for one of these situations to occur.
At the end of the day, your direct reports view YOU as the company in a lot of ways. You are their main interface to the rest of the machine.