Principles of Engineering Management
acjay.com
acjay.com
> Facilitate wellbeing
> Personal safety, dignity, and wellbeing of every team member are paramount. Team success is only success if team members feel good about it.
But then you become an actual manager and realize that these are largely just feel-good aphorisms that don't really help navigate the hard work of being a manager.
Don't get me wrong: I think "facilitate wellbeing" and similar tidbits are valid advice. Likewise, a manager who chooses to not facilitate wellbeing would clearly be in the wrong. But when you get into management you realize that the hard work isn't waking up and deciding to facilitate wellbeing. The hard work often involves making unpopular decisions, or telling someone "no" when their pet request wouldn't be in the best interests of the team, or defusing interpersonal conflict among two team members who have been feuding for months.
These feel-good blog posts seem rather vacuous after being in the trenches of management for several years. Again, not because the advice is bad or wrong, but because it's just a lot of text around the basics of being a decent human being. Learning how to do the hard things about management or how to make unpopular but necessary decisions is something that you won't learn from the average blog post or LinkedIn post, largely because these function more as personal branding pieces than actual advice.
In my experience, the best management advice comes from talking to the best managers you know personally. Online, the most practical management advice comes on smaller forums where people are either anonymous (and therefore less interested in personal brand building) or older and accomplished (and therefore not worried about blowback impacting their career). The type of feel-good blog posts or LinkedIn blurbs that people associate with their personal brand don't really add much value after you've read 5-10 articles saying the exact same aphorisms.
My instinct is to push hard, let "the most correct" idea win, and not really give a shit about how it impacts others. All, as you know, awful, very bad, no good ways of managing. Being reminded that one of my primary jobs is to "facilitate wellbeing" helps keep me grounded.
Let someone take the day off even if there's a deadline looming, be cool with a later start date than would be perfect, take that vacation week and really don't plug in, a) for yourself and b) to show that as acceptable behavior for your team to do as well.
None of this is how I, naturally, would behave, and I need to be reminded and continually work at doing things like that, for the sake of the health of my team. None of this is theoretical in my view, I see it as specific and practical advice.
However, the specific word used by the OP is "Facilitate" which gives managers the leeway to be weak and lazy. A manager can say "I let my team take PTO a few days each quarter, I facilitated their well-being!" while they passively allow their stakeholders to dictate the workload of their engineers, with zero pushback. In practice, "Prioritize" basically means conflict and action, "facilitate" means whatever the manager wants it to mean.
Going further: most "principles" like the kind the OP wrote are designed for a manager's self-therapy. Beliefs that justify decisions the manager has already taken, dressed up in nice-looking words, the kind of drivel that influencers peddle on LinkedIn. Whereas real principles that the GP refers to are meant for self-discipline. Beliefs that call into question decisions, and force the manager to really think their next steps through carefully.
Judging by the trends observed in the Great Resignation [1] and the popularity of forums like /r/antiwork, it seems that the basics of being a decent human being are often being overlooked by management.
I took a very different interpretation of what facilitating wellbeing looks like than you - interpreting facilitating wellbeing as being flexible when team members need some time to navigate their personal lives, scheduling project timelines and scoping work to necessitate productive work while alleviating burn-out, providing space for people to discuss ideas or provide feedback in a team setting, allowing for growth or transition into roles they may find more interesting or rewarding. Facilitating wellbeing doesn't conflict with making necessary but perhaps unpopular decisions, or de-prioritizing a pet project or whatever - it's much more basic than that.
[1] https://www.shrm.org/resourcesandtools/hr-topics/talent-acqu...
People working in tech companies may not realize how un-decent a lot of other companies and their management are.
Like the author said, actively improving the working environment when possible earns you "currency" and trust into making unpopular decisions easier to swallow.
Openness because you should be able to communicate why something might not be possible in unambiguous terms; honesty so people know they can trust you and that you will tell people the truth and not try and avoid it; and balance because you will be prepared to go some distance for an employee for the benefit of the business but this is not unlimited.
It can be hard to tell someone they are not performing well but it is much easier with those principles in mind, "I think these are areas that you are not performing well in, if I can help you achieve those then please let me know how, otherwise I need someone who can do this job that you were employed to do".
There's no playbook for being a good manager the same way there's no playbook for being a good partner or a good parent. The playbook would have to be too generic or too specific and end up being mostly useless.
Best you can get is someone who genuinely tries to improve and listens to you because they seem to care about you. If that takes the form of "how was your weekend" in the beginning of a 1-1 or having your back in a compensation review, that all depends on the situations.
I have all respect for Marquet and I agree with most of the things he says about leadership, as well as try to apply it daily myself. But my best reading of Taleb is that the sort of thing Marquet does (potentially get lucky, extract oneself from the situation, and then live off of the one experience), that's the opposite of skin in the game.
He tells people how he invests, and some theoretical consequences of tail risk depending on input parameters.
It's a small difference, but, from what I understand, a meaningful one to Taleb.
I realise I'm just plucking a small point out of a large comment here, but I'd like to drill down into this one a little.
My very limited experience is that teams can generally self-manage this sort of thing. You tell them what you're trying to optimise, under what constraints, and lay down some ground rules for equal and fair participation, and then the team can make their own tough decisions and tell each other when they're not acting in the best interest of the team.
What am I missing?
My experience is that they can absolutely not self-manage these things, it leads to literally living out lord of the flies in chaotic and dysfunctional teams, that are full of infected conflicts and stalled progress.
On the other hand, what exactly is it that gives you the impression that decision making is suddenly not needed? And what makes you believe that a group of people with different goals and interests, should spontaneously just "get along", especially when there's money involved?
If your team consists of mature, kind, focused, skilled, honest, emotionally well-regulated people, then yes, the team can self-organize well.
That's very, very unusual, though. I don't think I've personally ever been on a team that consisted solely of such people (and, to be clear, though I strive for those things, I wouldn't say I've got them all nailed down perfectly).
I think the lack of specificity is a fair criticism of what I wrote in the piece, but this is also something I was very aware of when I wrote it, which is why this caveat is included:
> The management principles below reflect lessons I have learned the hard way. These are things I wish I would have known and internalized when I first became a manager. By keeping this brief, I hope that it will be easily consumed, perhaps at the cost of people being able to fully understand each point.
Maybe at some point, this expands into multiple pieces or a short book, but for now, this is what I've produced. It won't be specific enough to be useful to everyone, but hopefully some folks find it helpful.
There is no manual to being a good manager. Only ideas you can project into your own approach.
When managers of unrelated industries come up with some similar preferred practices, that can show fair agreement that it's more likely to be worthwhile.
People need to realize there are lots of companies that fail on almost all of the eleven points you have here, and if the right key person were to just take your page to heart and follow it with action it would be like a breath of fresh air across the entire project environment.
Like they have never seen.
Most of those critical of what you wrote haven't had an article like this happen. Don't sweat it.
Thanks.
1. Managing comes first. (Nope, as a manager your are primarily responsible for ensuring a good outcome. As your title goes from manager, senior, higher to VP etc this becomes more important. Lower job titles you get paid to "do the work", higher titles are about "achieve outcome".) In the current market you'll often run into team members that don't perform. I see this so often where leads think that they have to "manage" and not do the work and the result is them and their team failing 2. Facilitate wellbeing. That's nice. But your primary responsibility is to A. Achieve the goal. B. hold people accountable to an acceptable level of performance
Give credit, take blame: That's a good one.
This post is just full of vague language that doesn't hold anyone accountable. Sucks to be an IC on that team, thinking everything is going well and eventually end up having whole teams being fired since your manager didn't set the right pace.
If you can't trust your team to do the work, then you shouldn't be managing those people. Management is about being a force multiplier, and not the force.
At the moment I have flexibility in how many people I hire underneath me and would like the team to remain small enough where I can be both a force multiplier and part of the force. The goal is to be an elite small squad.
The other option is to hire a larger number of people, handle more of the project scope, and cease being an IC. However I'm new to being a formal manager and am guessing this would probably be bad for my sanity.
It's mostly because of conflicting mindset and commitment. As manager, meeting is your tool to get work done (source: High output management by Andrew Groove, I didn't make this up, and I didn't understand it until after I had to become a manager either). As an IC, meeting is a big giant distraction to you. You basically can't get the two type of works to mix together. You will always be blocking other members of your team in your IC task. And this doesn't get started with the different mindset yet (For example, you have to watch/ teach people fixing ugly code, as opposed to doing it yourself. And there will be some point you have to give up asking polishing certain piece of code, due to the members not interested, incapable or other reasons).
Being a manager and part of the force should only be a transitional period.
But in fairness, "achieving outcome" is equally vague and it seems most leaders know they want Outcome X, but falter because they don't know how to get from their current state to that end state.
Can you elaborate on how you'd fill those gaps of "achieve outcome"?
I hear what you're saying, but I would be careful taking a military type model and applying it to a team of software US engineers mainly because I think the power balance is so different.
If I'm in the military and I tell one of my subordinates that they need to dig trenches in the rain all weekend for the next 6 weeks, they may bitch and moan, but they've signed a contract so they're just kind of stuck. If I tell one of the engineers on my team that they need to work weekends for the next 6 weeks, they can probably have 3 interviews with other companies lined up by Monday.
I agree that achieving results is still priority #1, but the distance between that and #2 is very different.
Leadership capital is a perishable resource in the military. Junior troops are not dumb and if you treat them like crap and just use the justification that they signed the contract, you won't be a very effective leader. If I leader has to use that type of tactic (or use their rank, or whatever), it's an indicator they've messed up somewhere along the way. The power dynamic isn't as cut-and-dry as most outside the military think. It's not unheard of for junior troops to get a bad leader fired, and in the absolute worst cases junior troops can put a poor leader's lives in danger. The idea that good military leaders would tell their subordinates to pound sand because they signed a contract is more of a trope than reality.
There's a surprising amount of times when the incentives align for a military subordinate to NOT listen to orders and leaders have to actually rely on the social capital they've accumulated by building trusting relationships with their subordinates.
I think those managers that ask their software engineers to pound sand are generally going to be bad managers. Notably, who should you ask advice from, someone that has designed 10% of the system specs, or the person that designed 90%? (Guess what, software engineers design about 90% of system specs!) Citation needed, but the amount of specifications that engineers have to fill in is quite mind boggling (what happens to this web page if DB is slow? What happens when a user clicks this button while this other thing is still loading, etc..). So while the 90/10 split is an exaggeration, the point remains, software development is a highly collaborative activity, particularly with the engineers. Some have said that a software's engineer main job is to figure out how to achieve 80% of the benefit, with 20% of the work. This aspect is missing from the typical unit-level command and control example, notably the "commanders" in software really don't know what the hell they are talking about unless they engage in actual conversations with the developers and users.
> end up having whole teams being fired since your manager didn't set the right pace
Whatever work exists where a manager can control such things as "pace" and "performance level" it aint engineering.
I don't know what sort of company would respond by firing the whole team, though. If a manager fails, the manager should be out, and a new manager should try to turn the team around.
I find this so important. A good manager has a good mental map of the business's short-term and long-term goals, and a corresponding map of each person on the team's short-term and long-term goals (and strengths/weaknesses) . This map requires constant updating and refining. The magic happens in finding the right fit between all of that.
A healthy team has a good understanding of one another's strengths and weaknesses just from working with each other. A manager should be trying to collect that feedback, as well as use their own, then work with each member of the team to determine what opportunities they need, to either demonstrate a strength, or work on a weakness, and then create space to socialize those needs. With the team aware of what one another needs, they're able to all be on the lookout to identify and highlight those opportunities.
Once the items the team definitively owns are being optimally allocated by the team, the manager can look for opportunities outside of the team's domain. They don't even need to be for specific individuals, but things that the team would be able to reasonably help with; then pitching them to the team, the team can self-organize to determine who it's an opportunity for (and then further break it down; maybe person A needs the opportunity to lead a cross team initiative, but person B needs the opportunity to dive deep into a technical implementation, style of thing).
Last but not least management is about gaining, using and maintaining power. Without it saying no is not possible.
However, there's another side to the manager's job that doesn't seem to be addressed - interfacing upwards with whatever layers link to owners, founders, the board, shareholders, etc. How does that exactly work out in practice? Let's say leadership makes what you think are really stupid decisions with disastrous longterm consequences (ex: Boeing 737 MAX design process, Google signing up with China to build Dragonfly, etc.). What do you do? Pour gasoline on yourself and set yourself on fire in protest, or roll your eyes in despair and proceed to assign your team to the task?
- Provide data to make an argument
- Put your concerns in writing
- Challenge your manager to ask their bosses tough questions
- Form coalitions with other managers to try to solve problems together
- Ask for a skip level (IMHO once a quarter, not just to address business problems but to maintain good relationships)
- If your employees are still at risk and upper management does nothing, threaten to quit
Some of them are difficult though, for example:
“optimize the dual objectives of delivering value to the organization and giving individuals problems that build their skillset, impact, satisfaction, …”
and
“ Managers with excellent execution skills and deep domain knowledge must resist the urge to present solutions to their reports.”
To what extent should one allow suboptimal solutions, failure or allow employees to do things inefficiently with their “favorite tech stack” (in cases where it does not add business value) ?
100% of the time. After all you can't count yourself being there to 'save the day' every single time, so whats the point of interfering here and there randomly.
This can be quite stressful though — I do not think the people reporting to me understands how much energy is spent as a manager negotiating with others in order to give the team and team members the most space/maneuverability that is possible.
Speaking from experience as an IC -- managers do an absolutely terrible job of surfacing what they're working on.
What are you doing to broadcast your efforts? If you don't tell them what you're doing, you can't expect them to know if you don't tell them.
If you do have a team that large, then you need to have a weekly or biweekly meeting with an agenda set beforehand. You can make announcements and possibly have a rotating presentation by somebody from the team about what they've been working on.
If you are managing this many people, you are managing people, projects and comms.
For things that are much more personal -- allowing suboptimal solutions for example -- those are teaching moments. You don't dictate the solution, you educate on the problems that the chosen solution exhibits and provide resources. Make requirements clear. There's a decent chance that if they're presenting a solution that you find suboptimal, then you haven't communicated the requirements properly. Surface them and re-scope the project as needed. Be sure to double check that the things you're finding as suboptimal are actually important as well. That is, don't be arrogant -- there's plenty of room for the error to be on you, and that you're assuming something may be suboptimal. Also consider that the person in the weeds may have more context than you, and there may be factors you're not considering.
Rely on concrete things like tests and metrics to guide those discussions, so you're not evaluating on subjective matters. Don't put value judgements on solutions, frame things as decisions with trade offs. Those trade offs have ramifications that you can discuss, and together you can navigate to a workable solution.
Ultimately remember that even though you could give into the urge to present solutions, it is not your job. Focus on your job, and help your reports do theirs. If you don't like that, get a different job.
All solutions should be put out on the table as business tradeoffs. "It will cost X; we will get Y; we might run into unexpected problem Z". We all need to agree that we want to choose the best solution for the company, we lay out the solutions naked and vulnerable, we pick them apart, and then we make a decision. If we still can't make a decision, we let someone take the sword - potentially making a bad decision in the process - because we agree that forward progress is more important than total consensus. Will we always pick the best solution? No, but hopefully we've come to agreement as to what the pros and cons of each solution. We likely had to make a decision on several shades of grey. Still, we should be held accountable for our decisions regardless of how difficult they were
There's a huge difference between asking questions about an approach and prescribing an approach or saying "Nope that's not the right way" and there's a ton of room there to avoid the really suboptimal stuff.
A lot of what I'm looking for in a boss is just someone who kind and understanding. It's shocking how low that is on most managers agendas.
Also: Why doesn't the other person know you've "moved forward"? Try communicating that you have.
Every once on a while you come across someone that is enthusiastic, actually competent, and wants to do things to the best of their ability (or a reasonable approximation thereof), but those are few IMHO.
I mean, I know not all people can be interested in all things, but if you say you're up for something, be it a job, project, or partnership, you've got to give it your reasonable best.
I think the need to be kind and nice all too often is abused by their targets. The key is to find a way to be kind and flexible, but not allowing that to paper over rank incompetence or a bad attitude.
You can have high standards and expectations and still be nice. In reality no one is going to be operating at 100% all of the time. They will have good days and bad days. I assume that others are doing their best. If their best is not enough for the role they were hired for than I made a bad hire. If I cant find a way to communicate expectations and standards without remaining nice than I'm the one taking the easy way out.
It's easy to be an ass and use emotion to make strong employees feel like they need to do better or deliver more. But at the end of the day your employees will leave once they have had enough.
I've left jobs I was highly effective at because my manager was constantly pushing for more and more. I would have stayed much longer if they would have had the EQ to recognize that I was operating at a high level and praise and kindness would be more effective in the long run. Who cares if someone delivers more of X when they leave in 6-12 months? Every gain will be canceled out by the amount of time you will spend finding their replacement and training them.
So to end my ramblings... If your point is that kindness can be abused... Sure. I agree. But is choosing to be kind and understanding, even if you feel like you are being abused at times, going to lead to you having significantly greater employee retention? Will choosing to act some other way cause your employees to leave which will drop their production from whatever % to 0% for an extended period of time?
- supervision (did you turn up on time, are you capable of doing the basic functions needed)
- coaching (this team needs someone to do X, but I have two Ys. One goes or one changes)
- administration (budgets, projects, scheduling etc). Certainly the part most at threat from software - looking at you Project Manahers
- strategic decision making (yeah that's the part everyone wants to do because it's the big bucks with years before anyone can judge you. It is also oddly under threat - not from software but from voting - my guess is most strategy is going to be voted for in twenty years. don't like the strategy - binding vote at the AGM for new Board. would save Elon the effort of buying twitter)
All four of these (and I am sure MBA text books have better selections) are wildly different, at different levels of an org and need different skill sets and people. just thinking we could ever ask one person to get on with it all is crazy.
What I really wish would happen, is that we'd abolish the title "manager" as overly vague and oft abused, and instead just call it what it is.
- Public Relations (go to meetings)
- Clerk (push papers, manage minutia)
- Meeting Caller/Planner
- etc
Anecdotally, an off the cuff euphemism from my Advanced Fluid Dynamics Professor in the early 90's still holds too true all to oft in my experience. He had great rapport with our class of ~100 students. After one test, the class was collectively whining about grading to a curve. After humoring us for a bit, he said something like "Look, you A students, you're going to go out in industry for a bit, but the lack of idealism is going to frustrate you, and you'll be back here soon with me. You B students know what compromise is. When it's good enough. That's why you're going to make great engineers." And then he turned to begin his lecture like that was it. And someone yelled out "wait, what about us C students." "Management" was his terse reply.
(Apologies to the venn intersection of managers <-> HN readers <-> "A" students.)
For me, I like having a budget and a staff - it’s way easier to influence my organization with a budget and a staff, than without.
I’m saying this only to encourage engineering leaders not to be afraid of formal management roles. You can make them your own. You might find what I found.
There are other ways to structure our corporations, our tax and investment incentives. The Early Victoria British style of corporate structure worked so it got copied naturally. And I am not saying there are easy fixes. But co-operative movements were born at similar times. One day we will see VCs funding co-op unicorns and the world will look differently
If a group of people performs/delivers poorly, how effective is it to assign blame to one select member? It may be efficient, but I’m not sure it’s effective.
This seems like a reasonable goal, but it is not actionable advice. "Prefer one on one meetings" is actionable, and it tends to enable you, as a manager, to facilitate wellbeing.
Forgive me for quoting my book, but this example is worth thinking about:
-------
Great news! You just raised a round of investment! You are flush with cash! Now you can hit those ambitious goals that you excitedly promised to your investors. In six months, you can go back and tell them that you totally crushed the numbers — not only did you make your milestones, you blew past them. The investors will be so pleased! Now we just need to tell your head of marketing to ramp up the customer acquisition! Luckily she has a genius for this kind of thing. Oh, wait, here she is now, walking over to you, about to say … … oh damn. She just quit? That was unexpected.
One-on-one meetings are useful for many things, one of which is that you aren’t likely to be ambushed by a surprise resignation. There are many personal issues that might cause someone to quit, and these will never, ever be mentioned in a group meeting. Burnout? A divorce? A spouse with a job in a different city? A child failing in school? A parent who is dying? Interest in other kinds of work? No one shouts that stuff in a group meeting, but they might tell you when you are one-on-one.
But what I often miss from posts like this is focusing on the value the group of individuals is meant to create (maybe it’s implied).
The biggest confusion I see in new and experienced managers is the point of their job -> maximizing their teams productivity.
It's not clear from the article that the author has realized this.
Making sure that the problems are the right ones to work on is pretty important as well.
Here's the real Principals of Engineering Management, according to pretty much every middle manager, director, and vp I've ever worked with:
1. Be caviling and pedantic, so you can reinforce your position of petty power.
2. Contribute exactly zero code, infrastructure, etc. Basically, anything that actually provides value to the engineers or the customers, you don't touch.
3. Put at least a couple meetings on the calendar every day of every engineer that they don't need to be at to remind them you rule over their time.
4. Push nebulous "goals", then have very set goals when it comes time to promote/give a pay raise an engineer and then insist they aren't quite there.
5. Put engineers on-call instead of hiring support staff, again to remind the engineer that you own their time, even when they're not at work.
6. Constantly seek updates from engineers, so many in fact that they can't complete the work on time, then promptly blame the engineers for not delivering.
"Managers" are people with business degrees who failed out of anything technical. Real managers are architects and PMs who actually understand the product and the technical lift it takes to actually make things happen. They don't concern themselves with your comings-and-goings, but whether you can get things done or not.
You might be right and every manager is terrible, but it's worth noting that the common denominator in all of these interactions is you.
Note that in some jurisdictions (including the USA) this is problematic from a labor law perspective.
Quite frankly, I wouldn't want to work somewhere that didn't. I have a huge problem with the idea of "my team wrote the code, and now isn't responsible for it". I intentionally optimize against "avoid 2 AM pages", and that ensures I push for enough testing and such to avoid them. If it was "someone else's problem", the only pressure I'd be under is to deliver ASAP, and that's unhealthy.
But it does make this career path rather miserable to me.
And those were not FAANG. So I think it's also the culture and expectations, and it's not ludicrously impossible to get. It just requires, getting back to the topic, a reasonable manager who understands the negative effects of getting paged.
I also acknowledge that failure to comply with labor laws and other regulations is widespread in the US, whether knowingly or though ignorance.
It seems to be the case in every job I've had. Maybe they ARE adhering to some laws but at the end of the day I get paid a salary, and I have on-call evenings+weekends which I don't select. I can swap shifts, but it's my responsibility to find a substitute. I average 4-5 shifts/months.
As far as I know, all of FANGetc is like this. It may be the case that labor laws permit this. Still miserable.
As an employee you have to consider the workplace culture, and your manager's attitude towards his/her "resources" (employees). This is a list of danger signs. You want to be watch for dysfunctional behaviors like this creeping into your work environment, and either combat them if you can, or find a new position. Or, you can accommodate/enable and try to insulate yourself, which is OK in the short-term, as you work towards a longer-term solution.
The culture of the organization and the management chain above you greatly affects your satisfaction and mental well-being. I assure you that, although no workplace is perfect, a few are pretty darn good. And sometimes it's possible to exert influence. Try not to sink too far into cynicism because there is a lot of incompetence and selfish self-interest out there. Use your skills of observation and writing to make things better, or find a place where that's possible.
Sorry if this is preachy.
I'm grateful to report that I'm in an awesome situation now and my manager and I get along swimmingly.
I think you would find it really interesting to try running a company or even a team. I think it would help you see your prior managers in a different light.