Ways to annoy your senior engineer
thecaringtechie.com
thecaringtechie.com
I did have a VP in a meeting go “I don’t like that estimate.” I pushed the dice over and said “Ok, you roll”. Their hand got about 1/2 way before their brain caught on to what was happening and they pulled their hand back.
We normally agree on them writing a 2-3 page scope and I do an estimate based off the scope. Slow learners ask, How long to get the estimate, I look them dead in the eye and reach for the dice again saying “I’d like to see the scope beforehand but ....”
Why can’t you idiots figure out how to code?
I have told a few people that when we substituted their judgment for mine this became their problem. I really think I should have said it more often.
https://en.wikipedia.org/wiki/The_Dice_Man
>The Dice Man is a 1971 novel by American novelist George Cockcroft, writing under the pen name "Luke Rhinehart".[1] The book tells the story of a psychiatrist who makes daily decisions based on the casting of a die.[2] Cockcroft describes the origin of the title idea variously in interviews, once recalling a college "quirk" he and friends used to decide "what they were going to do that night" based on a die-roll, or sometimes to decide between mildly mischievous pranks.
https://www.reddit.com/r/Teachers/comments/15c3yd4/every_yea...
>The newest thing here is a flock of self-proclaimed “coin boys” who carry a quarter on hand at all times and constantly flip it. They have their entire personality revolve around coins, coin flips, and chance. When we went around doing an ice breaker, 4 or 5 of the kids said some variation of “I live by the coin and die by the coin” as their fact.
>Just about an hour ago, when I assigned the first assignment of the school year, one of the coin boys was bold enough to say “heads I do it, tails I don’t.” I told him if he flipped the coin he would be getting a call home on the first week of HS. He flipped it anyway and it came up heads (thank god for that at least).
>But then the other coin boy in that class flipped his coin and it came up tails. He said the coin has spoken and he’s not doing it. I say very well, enjoy your 0 and your call home— what a great way to start off the school year and your high school career.
https://en.wikipedia.org/wiki/Flip_Decision
Didn't end too well for Donald and the boys.
> Proper estimations take time.
IME there's no such thing as "proper" estimations. They're all a wild guess with little basis in reality. Scrum came along to make us pretend that relative estimates ("story points") are somehow more accurate, but they're the same illusion.
Software development is inherently chaotic. Every task is different from another, and developers can only get a sense of the time and effort requirements once they start working on something. And these are constantly changing during development. It might take a long time to discover that a bug can be fixed by a single line change, or a chain of bugs might be discovered that need separate investigation, or a bug might not exist at all, etc. Every case is different. Additionally, every engineer is different, and they're different from themselves every time. Tasks that require mental effort are unpredictable by definition.
Estimates are useful to managers and executives to pretend they're in some type of control, but they're otherwise useless. They only serve to demotivate development teams when they're not met. I wish the industry would move on from them and adopt the more sensible approach of "it's done when it's done". Unfortunately, this doesn't gel with the rest of the business which functions on deadlines, so here we are.
Being on the other side of it now though, I really take issue with sentences like "Estimates are useful to managers and executives to pretend they're in some type of control, but they're otherwise useless". In the places I've worked as a manager, with the managers, directors, and VPs I've worked with, I've never gotten the impression from anyone that it's about control. It's about resource and risk management as well as ROI.
Developer time is a limited and incredibly expensive resource at most companies and managers need to make sure it's used in the most impactful way that it can be. A project may make sense to do if it's going to take a month, but it may not make sense to do if it's going to take a year. Without some sort of estimate on the time a project will take, you can't properly prioritize work. There are absolutely projects where it's just like, we need to get this done no matter how long it takes, but most projects aren't like that.
Again, I totally get your frustrations, but the thing I always tell my teams is let's say you wanted to build a house from scratch. You call a contractor and tell them everything you want done and then ask for an estimate and they tell you, "I don't know. It'll cost what it costs. Every project is different and I won't know until I'm done."
I doubt you would hire them, right?
You need more information than that to be able to truly make a decision because at a certain dollar value it's just not worth it anymore. You don't need an exact dollar amount, but knowing whether it's going to cost $100k or $500k will completely change the value proposition.
Again, I totally feel where you're coming from with pushing back on estimates, but I don't think you're ever going to get away from them. With that in mind, one of the things I've started asking my teams to do where they're really pushing back on estimating is to take a day and think on it and then come back and give me two numbers. Give me an estimate that you're 90% sure is too high and a second estimate that you're 90% sure is too low. I've feel like that takes some of the pressure off because there's no exact number that they can be held to and it gives me enough info to make a decision.
What kind of works is tracking similar efforts (in the same code base) and measuring how long they take. While every task is different, there are usually a small number of different classes of tasks, and knowing how quickly these can be done helps in both estimating as well as defending the estimates.
You're right one of the big problems is that people treat estimates as commitments and they're not that. They're called estimates because it's an estimate not a certainty.
That isn't an issue with the estimates themselves though. It's a culture issue. Saying estimates are useless and I'm not going to do them because my company treats them as commitments is throwing the baby out with the bathwater, IMO.
I see you haven't needed to hire many building contractors. "I won't know until I'm done" wasn't how the engagements started, but it's how they all ended up. When the budget's gone and they're only halfway done what are you gonna do, live with a hole in the wall and no running water? If you got a home renovation done on time or on budget (I refuse to believe both), congrats on catching a unicorn.
I know their number is going to be off, so personally, I mentally double any number they tell me, but having that starting point is important. If they tell me it's going to be $6k for a new kitchen, I can budget $12k. If they just went ¯\_(ツ)_/¯ then I don't even have a starting point which is way less helpful.
Projects across all domains face the same problems we do and yet the only domain I can think of where it's normal to not provide an estimate for work up front is US health care pricing and just about everyone has a pretty major issue with the way that is run.
“What’s your estimate? No, that won’t work.”
Don’t ever start that bullshit conversation with people. You’ve now signaled that they can’t trust you and now any “information” they give you will now be untrustworthy because you’re untrustworthy and turnabout is fair play.
If you’re trying to control ROI and manpower, you tell us what date ranges work for the org and we figure out what we can fit in that time. And if you don’t get any nice to haves in that initial estimate you might as well pull the plug now because everyone knows that scope will have to be shed to hit the date. And that we try to pretend anything different is happening is part of that illusion of control thing GP mentioned. If we can’t build a thing by whenever then it’s time to rethink the project. A different approach, possibly involving buying part of the solution instead of building the whole thing. Or we do some other project first that will teach us how to do this project better.
That's a different problem though. The issue isn't that estimating the project is useless, it's that you work with people who don't respect the estimate and think it's a negotiation.
I get that you're saying that in that situation the only winning move it to not play, but that issue you're identifying isn't actually an issue with the estimate itself.
> If you’re trying to control ROI and manpower, you tell us what date ranges work for the org and we figure out what we can fit in that time
I get what you're saying and it's a valid suggestion, but personally, I find it better to work the other way. Engineer estimates a best case scenario with all the bells and whistles and then it becomes a discussion with stakeholders as to what can be cut to fit the timeline.
The reason I think that is better is because most of the time features that an engineer priorities may not align with what stakeholders priorities or there maybe tradeoffs a stakeholder is willing to make once they see estimates. For example A stakeholder may say, I really want it to do X, so the engineer comes back and says X will take 2 months to build and that's that, but if the stakeholder has the full project estimate in front of them, they might go, I really wanted X, but it looks like we can do A, B, and C in the same amount of time as X and those three things combined would be more impactful than X, so let's do that instead.
Again, you're suggestion is totally valid and I'm sure many people do it that way, but I've gotten better results the other way.
> I've never gotten the impression from anyone that it's about control. It's about resource and risk management as well as ROI.
Don't get me wrong. I didn't mean "control" in the sense that they want power over the project. It's more that they want to feel that these processes make the project more predictable than it would be without them. This is what I argue is a fallacy.
Whatever estimates they get back from the dev team, and whatever extrapolated metrics like "velocity" they think help them get a feel for the team's productivity, is ultimately pointless. The problem is that these metrics are relied upon, when they're really no more reliable than not tracking them.
Your house example is how management wants to visualize software development, but it's just not an accurate analogy, and never will be. Software development is nothing like "real" engineering, despite what developers like to call themselves. When building a house or any real-world object, you can rely on physics to make time estimates. You know how long concrete takes to set; you know how long a machine takes to cut wood beams; you could even know how long it takes for a builder to lay bricks. You can then extrapolate this to the building requirements, and more-or-less give an informed estimate, where only unpredictable circumstances like weather or human-related issues could delay the project.
Whereas software development depends entirely on humans (for now, at least; AI is not reliable yet), and there's no predictable physical component to it. Every project is entirely different from every other. This is not like building a house, where most houses have something in common. This is like inventing an entirely new way to build a house, from entirely different components, every time. The problems you run into each time are wildly different. Even when using the same programming languages, frameworks and APIs, the interaction between all of these changes every time you put them together.
But I'm sure you know all this. I'm just saying that the exercise of estimates is pointless, and the value they bring to the company is an illusion.
I fully disagree with that. Yes, you can absolutely rely on physics to be predictable in physical engineering, but I'd estimate there are similar consistencies in software engineering. You know how long things like the built time take and you can get averages on PR and design doc review times. There are going to be parts of a project that aren't full of unknowns that you can probably accurately predict (e.g. I have to change the color and text of a button or I need to spin up a new Redis instances and did that same thing on my last project). If you're building a house though, there are plenty of things you can't predict, same as with engineering. You can estimate how much concrete costs, but if you're supplier is in Canada and all of the sudden there's a 25% tariff slapped on the import your cost estimate could be fucked. Alternatively, what if the bricklayer breaks their arm a week before they're scheduled to start? In almost every project in almost every discipline there are unknown unknowns, but that doesn't stop them from providing estimates.
> Whereas software development depends entirely on humans (for now, at least; AI is not reliable yet), and there's no predictable physical component to it. Every project is entirely different from every other.
I mentioned it above, but I could not disagree with this more and if you really feel this way, I think you're not thinking things through. If I build an API endpoint to return all users from a database, I can probably pretty accurately predict how long it would take to build an endpoint to return a single user from that same database. If you did a project to build the front end of a sign in page, you can probably pretty accurately predict how long building the front end of a sign up page would take.
Even on projects where the project itself is fairly novel, not every part of the project will be and that can be a starting point. Even if you're building something entirely new, if you know you need to add a new database table, you might need to look at what their migration framework looks like, but you can probably get a fairly accurate estimate on the time it takes to do that part. Most software projects aren't 100% work that you've never done before and even estimating that work can be a good starting point and be helpful.
I also really disagree with the idea that just because it's physical means it's predictable. Concrete drys slower in cold weather, so unless you have a 100% accurate weather prediction there's unknowns there. You may estimate it's going to take 5 days to build the framing, but if a freak snowstorm happens and your crew now spends the first and last hour of the day shoveling snow and covering/uncovering everything on the build site, your estimate is out the window. Even ignoring that, it's not like building a house is a completely automated process. Even if you know exactly how long the concrete will take to dry there's a lot of people involved in the process of pouring it.
The moment you get judged on your estimates they lose all value.
Second: But OK, those ones about shifting priorities? That’s startup life. Sometimes you throw something out the door because a customer wants to pay you $12M if you can salve over that one pain point. You know darn well that hack’s going to be there until The Rewrite (which, if you’re lucky, will never come). It’s ugly, you’re ashamed to have your name on the git blame, but your stock options went up 8% the moment you deployed to prod. The customer rarely pays you to be an artisan. They just want that feature before they write the check.
I’m still highly sympathetic to the sense of pride and ownership we all want to feel over our work. That’s the best! But getting paid’s pretty cool, too. Get a hobby project you can polish into a masterpiece after work.
I've seen it at pretty much all scales. I think it's usually worse in bigger corps actually. Great point though - it behoves us to remember where the money for our technical airs and graces comes from.
Capital-A Agile is project management for dummies that won't learn about things like GANTT charts, what "slack" means in links between dependent tasks, what a "critical path" is or how to analyze it, let alone things like S-curves and earned value.
Can you give me an estimate for these sixteen different things, and also verify which ones depend on each other?
Nobody ever figures bus numbers into the chart, because it would make the timelines so much worse that management wouldn’t approve it. But the blame for going over the estimates rolls downhill. Those stupid devs can’t get anything done on time.
Thankfully I haven’t had to look at one of those stupid things in about 20 years. They used to make me see red.
The fact that there are bad project managers that don't know how to use a schedule are just as bad as the crappy "scrum masters" and "product managers" that don't know what "agile" actually means.
A good project manager will be continuously revising their schedule, based on updated estimates on the tasks. They will know how to compare it to, and update, the baseline.
Not sure what you mean specifically by "bus number" but happy to learn.
The GANTT chart is just a format of displaying tasks, their resources and dependencies. The actual DAG is a pure data structure.
If you put a confidence level indication on the estimates, a good project management tool will also be able to do analysis of the critical path (ie the length in time of the longest path) with a level of confidence on earliest/latest predicted end dates.
People think that nonsense like "t-shirt sizing" actually means anything other than "wild-assed guess" or that burndown charts are useful when adjusting future estimates.
All techniques to avoid doing the hard work of scheduling and project management.
And if you don't know how they are dependent on each other, then how the hell are you estimating each of the 16 different things anyway?
I guess my main point is that you have to always be making the right thing. Sometimes that changes, and you have to be ready to pivot quickly.
It's very easy to see the PMs etc. as the enemy, but they would have their own list of unfair gripes about engineers (e.g. as evidenced by this article, they seem to just want to be solitary geniuses left alone to work on things they aren't communicating about).
1 + 2: Tell them to open a ticket, mark it appropriately, and we’ll do it; but then when you come asking why we didn’t do other things, I’ll show you that chart.
4 + 4b: As a senior engineer, it’s literally your job to interface between leadership, PMs, and junior engineers. “Sync” usually means they want some time to chat about whatever comes to mind — make sure you regularly have these with all major stakeholders. Block out dedicated work hours, but let people consume your time outside of that — it’s your job.
5 + 7: Your job is to manage that we’re paid for features not craftsmanship; hacks are inevitable, but you should leave slack for improvements, document the business case for major fixes, etc.
3 + 8: Along the same lines, help leadership figure out a plan. Unavoidable thrashing happens at times at a startup, but even then, you should talk about roadmaps. Help leadership split the effort between long term goals and immediate payoffs; help them understand priorities.
There are people happier remaining at career IC levels (SDE2 at Amazon) because they don’t want to do these things — and that’s perfectly okay, too.
* getting an idea if something is worth doing
* picking between things that are equally valuable but may be differently expensive
* rejecting things that are estimated to take months, as that means we have no idea and need to break it down more
* making the scope more explicit
Estimating is not useful for:
* planning a release date for the thing you haven't started yet
"Could we have a meeting with your coworkers so you convince them this is the best course of action?"
I'm not a salesman or an evangelist. I'm a tech person and actually the local expert in the subject, a fact that you constantly advertise to the board. If you trust me, make a decision, it's your job.
Instead of that, you book the meeting, make me explain what we should do (that you vehemently agreed on before) and, when the others frown (the juniors because it's work, the seniors because it's change) you reverse the decision and quickly rebuke me and tell me we'll do it gradually (=never).
The closest to that is half-assing the task at hand and multiplying the time it took by ten. For prototype to actual application, you multiply it by a hundred. This also applies for the prototypes of the prototypes (100x for the actual prototype, then 100x of that for the proper implementation), and yes, those exist, but they are usually named "concepts".
For bugs: Half the amount of time needed for the feature that caused that bug. They need a workaround? It will actually take longer - except when the workaround is already available and just needs to be applied. Then it's 90% of the proper solution.
You seem to be missing the point of 'estimation' (as in, it is an approximate prediction, not an accurate measure). Admittedly management also tends to miss this same point, and that fact puts a lot of us on the defensive - but the answer can't be to throw estimation out entirely.
If you ask a civil engineer to estimate the cost and timeline of building a bridge, they'll get you an estimate. It'll likely be within 1-2 orders of magnitude of the actual cost/time, due to a bunch of unknown-unknowns that are hard to factor in (things like: how long the legislature will take to permit the build). But it'll still give you useful data about the differences between building a $million foot bridge, and a $100 billion highway bridge...
If one needs more information to articulate the issue at hand, get it. If the estimate is being misrepresented (ideal days vs calendar days), clarify. If methodology is uncertain, do it and iterate and improve it with experience.
Playing coy about how long it takes to build a deck based on a sketch and current availability, while making cute wordplay about how ‘the deck has to be built before one can know what deck there was to build to begin with’…? Whatever, Confucius, it really doesn’t sound like there’s enough deck building experience here, and the obfuscation seems unserious and anxiety related.
Ouch. Usually the ones writing very aggressive comments filled with attacks on stereotypes are the ones with anxiety problems :) You are fighting with the windmills. I do make estimates, and I'm usually better than many at it. It doesn't mean that the others like my estimates.
Also, you didn't even understand what I'm saying. TL;DR: You need to allocate a considerable amount of time on analyzing the task to make the estimate (around 10% of the time it'd take to solve it). I also take a jab at people injecting workarounds for the sake of keeping it in the estimated time and failing.
Yes you’re an engineer and your time is valuable but you don’t have to act like it! Even if getting distracted causes you to lose some threads, you can’t ignore that you’re helping other people in the meantime. If you’re emotionally upset when you’re helping people they’re going to feel that and not want to try their best.
A company is not successful because of individuals, it’s the cooperation that causes the whole to be greater than the sum of its parts.
For example, reread the following paragraph:
> Few things are more disruptive to engineering than constant priority shifts. They make it impossible for engineers to plan or finish meaningful work.
Again, reread it and try to understand why the author stated that, instead of accusing them of taking themselves too seriously.
The problem is, if a leader asks for 3 weeks of work, and then every week asks for a different 3 weeks of work, nothing will ever get done. It belittles the engineer because that engineer isn't able to make positive contribution.
I suspect that you believe that engineers are merely pawns in a political game. Ultimately, companies that operate this way fail.
I think handling priority shifts is a part of the job. If you can’t get people to talk to each other about priorities and help illuminate that they have to compromise on what is important in order to get the best outcome, then you’re failing as an engineer.
However I do work at a company where I have an active hand in planning the roadmap as a senior engineer. I often tell the senior leadership what my thoughts are about priorities and I feel empowered to say “no,” or “let’s do that later” to asks. I understand this isn’t how everywhere works. Maybe the author and I have very different work experiences.
To me, if someone says “we are shifting priorities.” I think of it as a chance to improve what work we are doing. I feel that the author would see it as an opportunity to waste their time more.
I don’t believe that engineers are pawns in a political game. I think it’s a strange thing to suspect and I have some doubts about your mental well being. Looking through your other comments, it seems to be a common trend of yours to speak of people as pawns. Perhaps you feel like you are a pawn at work? Or maybe you see the world as a political game where you are a pawn?
I don’t think that’s a wise perspective - even in chess a single pawn often can win the game. Even with even pawns, the better coordinated pawns can win. Just some food for thought.
I only use the term "pawn" in this thread to set context: In a workplace where leadership exhibits the behavior described in the article, they have lower respect for their engineers than the workplaces I've been in.
I'm here to solve problems, not being emotion consult.
I didn’t see much of the ”highly sought after” bit in the recent years. On the contrary, the job market looks employer-friendly and the strategies for recruiting senior engineers seem increasingly backwards. Or is it expected that good senior engineers skip recruiting and rely on networking alone?
Pretty much, yeah. I don't know anyone at a senior-or-above level who spends much effort sending resumes through the front door.
But the bigger issue is that nobody else has memorized your code. So they have to fit the entire codebase as it currently exists into working memory. And since that is impossible it can take them months or even years to get as proficient as you are. Because they have to memorize it piecemeal to understand it, and unlearn false assumptions they couldn’t disprove until later. And meanwhile you keep adding new changes to the code. That’s a you problem, not a stupid coworkers problem.
If you’re very friendly you can bring a handful of coworkers along so you have the bus numbers, but any new hire still has the cognitive load problem.
The way out of this is to eschew “power” (Principle of Least Power), condense the core of the problem to its essential complexity, and write discoverable code - code that leaves breadcrumbs that invite a curious user to peek into functions where the real work is done. Which for instance polymorphic recursion absolutely does not do.
Getting the real senior devs in the enables and protects the process. Whether that process is winning depends on the total culture of humans segueing over things they want.
And I can see if they are making progress and where they might be hitting difficulties. (Most roadblocks have nothing to do with the tech. It's usually either some organisational barrier or a personal issue.)
‘As small as possible’? (Aka optimistic)
‘As accurate as possible’? (Aka as low variance)
‘As conservative as possible’? (Aka least likely to ever be exceeded)
‘As cheap to estimate as possible’? (Aka lowest overhead)
Most people have no idea which strategy they are even doing.
A 1 hour job will take 2 days.
A 1 day job will take 2 weeks.
etc.
When I say 'it'll take a month', I usually took into account testing and deployment, so it usually take a month (and a week or two because I still overestimate myself).
When I say 'it should take an hour/half a day/a day', yes you are definitely right, and my manager is in trouble.
The best way to handle situations like this is to leave, quickly! Companies that operate like this don't last long, because someone else will come and out compete them.
Edit: One thing I do when interviewing, is when I talk to the manager, I point blank ask, "how often will I be asked to change a task before I complete it?," and, " how many meetings will I attend during a day?." It screens out situations like this very quickly, because the managers who are looking to hire pawns won't hire me after asking questions like that.
If you find these situations frustrating, I agree. There is little hope of changing how software development is done in these companies.
> Companies that operate like this don't last long, because someone else will come and out compete them.
I take it that you haven't worked in many corporate environments. This is how software development is done in many, if not most, large companies. Their only competition are other companies with the same processes. Smaller companies can operate more quickly, and sometimes this can be a variable that helps with disrupting established behemoths, but it's usually not the primary one, and it takes many years to do so.
I'm mid-career and I have worked in all different sized companies. That's why I explained how to avoid these situations.
You don't have to put up with being a pawn, nor should you encourage others to put up with working conditions like this.
Edit: I was in situations like the article describes twice.
The first time was when I tried to start a company. It took me over a year to realize the guy I was working with was just an "idea person," who couldn't stop letting his imagination run away. We could never work on a hypothesis, because every other week he had a new idea and wouldn't follow through on last week's idea.
The other time was a startup where I built an industry-leading product. It was usually middle management and inexperienced people who acted like the article described. Upper management would intervene, and often people who acted like the article described got pushed out of the company.
I interviewed with a company that was "disrupted" precisely because of this way of working. (They have a well-known interrupt-driven culture.) They were a major vendor, and were trying to move their business into the area that finally disrupted them. (They were a major choice in software projects in the late 1990s and early 2000s, then lost business due to competition, and then changes in the 2010s really ate into their market.)
I took the interview for "career development," and generally planned to decline the job unless it was huge bucks. During the interview, when I asked the manager about interruptions, it became clear that they were the kind of place that the article described, and that's why their initiative is an "also ran."
Anyway, in the area they were trying to move their business to, no one generally considers them a major player. Their three major competitors are mentioned all the time, but their name rarely comes up.
I consider them disrupted at this point: Both in their product that had success in the 1990s and 2000s, and in their ability to adapt to market conditions established in the 2010s and firmly expected today. They could move into today's market if they had a better way of working, though.
I hate meetings without agenda. Honestly send me a message and I'll make sure I reply. Meetings with written agenda are great.
I would love something like Hacker News, but for indie makers, entrepreneurs and bootstrapped startups. Is there something like this?
In theory, you're asking for hacker news, it just happens to be that there's many different communities represented here.
The tyranny of the front page means you're probably missing a lot of the posts that you might want to see. And people aren't making many of those posts because they know they won't get seen by many people.
It can be kind of sad to see firms at that stage, but worth learning about what other people are doing in your area.
Best of luck =3
This same shit also goes on at all the 10-person startups formed by former-enterprise folks, which covers a pretty big swathe of hacker news audience
As a lifelong prodigy manager I much prefer stuff like “here’s the spec, how long do you think it will take to type the code in”.
I used to work for a Japanese corporation, and, when meeting with Japanese managers, you’ll see that they have a small notebook, open on the table, in front of them. Occasionally, they will jot something down in it.
You will also note that, whenever a date is mentioned, something gets written.
You are now being held to that date. They will completely leave you alone, until that date, when they will expect you to deliver “what was promised.”
In my experience, Americans never took this seriously, and it could be a real problem.
Of course that's an exaggeration, but I've always found software time estimation to be difficult compared to actually writing the software and usually not very accurate.
All of the issues in this article are about coders that are cogs in the SAFe/Agile machines that now infest software development.
NONE of them are relevant to actual engineering, software or otherwise.
These apply in concept no differently to building a bridge or a distributed software system.
There may be many who are just code monkeys but that doesn't mean some aren't practising engineering.
[1] Art in the sense that it can be perfect in its own right. There is no perfect engineering - everything is to a requirement and result of an optimal compromise.
In my last company there was a new top priority every two weeks. And i still had a very junior team who needed a ton of mentoring and development to be able to turn things around quickly. Who were then getting blamed for not hitting impossible-in-the-first-place deadlines.
> Engineers juggle a million things at once.
Eh what? If that's how your "engineer" calendar looks like then your org has more serious problems than a spontaneous "30 min sync" popping up in your calendar.
What is a "senior engineer" anyway? Everybody beyond intern stage is called "senior" these days.
They’d rather speak than type.
Alignment and understanding the product: As engineers it is easy to dismiss their task as conveying how the product works and defer to "it is implemented!".
I have stup a goal to post in the non-engineering Slack channels at least a couple of times with a video of how new features work, or give a short introduction on "that new testing framework" in human language.
Doing so is first and foremost a proactive move. Secondly it takes away the excuse of not knowing what eng is up to.