Not included in this list but definitely worth mentioning;
- Lowering your hiring bar. When you hire people the burden to get them up to speed and productive is on the existing team. If these people are smart and motivated, great! But no-one benefits from having 200k+ engineers now have to spent their days explaining how GIT (yes, really...) works to a small army of juniors.
- Not involving your current team in decisions that affect them. Re-shuffle the teams around, re-architect the product, change the existing workflow, etc. If you hire professionals with 10-20+ years of experience just to ignore their advice, they're going to be looking for an employer that does appreciate their input very quickly. Nothing is more frustrating than telling a manager not to put his hand in a pan of boiling water, just to see him do it and then blame the cooks for having a pot of boiling water around :)
My current manager decided to add 50 outsourced engineers to a team of 5 to deliver the product in a year (instead of the 1.5 - 2 originally guesstimated).
In addition to this he decided to give the responsibility for the architecture of the application to outsourced "solution architects" with no domain knowledge and reorganized the teams to split them by job title (e.g testers, developers, operations, "management", etc).
Current productivity is lower with 55 than it was with 5, 3 out of 5 have already handed in their resignation. We're burning through an additional 3 million this year with 2 crappy React pages to show for it.
Next year the damage will probably be worse given the rapid outflow of talent.
> have to spent their days explaining how GIT (yes, really...) works to a small army of juniors.
I sympathize with the other comments explaining that Git is highly nontrivial, but I think the point is being missed. Why should I have to teach a junior how to use an essential tool of the job, when I can just point them to good books/guides on the Internet?
My list would definitely include:
Hire people who can and are willing to read. Be it for learning or for understanding specs.
I'm not one of those people who gets upset at people coming to my cube to ask questions - I actually enjoy it (far more than them IM'ing me). But if it's something easy to find on the Internet, or clearly documented in a local wiki/manual, they should have at least tried to read it.
Similarly, I'll take the time to document very well how a tool I built works. Almost always someone will then come to me and ask "Hey, can you tell me what the tool does and show me how to use the tool?" Over 90% of the times it's not because my documentation is bad (which I admit it very well could be), but because they didn't even try to read it.
Reading is a huge problem with certain developers.
It's not only documentation, which they ask for but never read. They also won't read error messages, and ask seniors for help on almost every situation.
(But the most infuriating thing is when they assume the error message doesn't have any info, and when sharing the screen you have to repeatedly ask them to not navigate away because you're reading it)
> (But the most infuriating thing is when they assume the error message doesn't have any info, and when sharing the screen you have to repeatedly ask them to not navigate away because you're reading it)
Oh yeah - this drives me nuts, although I've seen it more from laypeople than developers. Some people are hard wired to just hit Enter for any informational window that pops up on the screen. I've talked to people who have no idea they're getting errors: "I just hit Enter so I can get to the program."
How about just making branches and merging? Why do I need to explain that to an employee? If they can't do with git very basic things it's because they're not willing to read.
What you need to shepherd them toward is not the commands to run to branch and merge, but the why. Why are branches useful? When should you merge? What do you do if there are conflicts? Most of this stuff isn't book material. It's what senior developers should be teaching junior developers.
Although the original commenter referred to junior people, I'm often having to explain these things to those who are not - sometimes to people with more experience than I have (e.g. 15-20 years).
Besides, there are plenty of online resources as well as books on the purpose of branches, and its benefits. Some of these have been around since before Git existed. I don't have a problem explaining the why, and pointing them to resources. It's the inevitable "OK, but how do I do that with Git?"
Extending it a bit: I often work with people who will never read a manual. They'll want to find a quick SO answer, or a short tutorial for everything. But once in a while, you need to read the man page, or the official docs.
Ok you convinced me that you're approaching this in a reasonable way. I also eventually check out from helping people who I become convinced are unwilling to help themselves.
> Why should I have to teach a junior how to use an essential tool of the job
Why shouldn't you? Unless you're a junior developer yourself, mentoring and developing the skills of the rest of your team is an even more important part of your job than whatever programming you're doing.
Because I expect people to have basic reading and Internet searching skills.
As I mentioned elsewhere, I don't have a problem mentoring them on what skills they should learn. I also don't have a problem directing them to resources where they can learn - even telling them what to focus on and what not to focus on. But I expect that once I point them to a resource, they'll go and read it. For things that don't have good resources, or if it's just a small tool/library that's not essential for their job, I'm happy to walk them through it.
Put another way: If you were my boss, would you want me to spend my time teaching the same basic Git usage to every junior hire? Teaching the same stuff over and over again? Wouldn't you rather I either write docs or make a video once and just have them watch it? Or even better, just point them to the many existing docs/resources out there?
> Put another way: If you were my boss, would you want me to spend my time teaching the same basic Git usage to every junior hire?
I guess I think it depends. I think some companies absolutely do need to take this on, hiring very green brand new hires and investing a large chunk of their more senior engineers' time into showing them the ropes. How else would it get done? I don't mean only for this specific example of git usage, but every entry level employee - whether from a college program or a bootcamp or self taught or whatever else - is gonna have a lot of gaps, and the company, and thus its more senior employees, should recognize that it's their job to mentor them through those gaps. Personally, I think companies are too hesitant to hire truly entry level employees and invest in training them.
> I don't mean only for this specific example of git usage, but every entry level employee - whether from a college program or a bootcamp or self taught or whatever else - is gonna have a lot of gaps,
That's understandable - the issue under contention is how to address the gap. I absolutely do not expect people to know Git when they start. If you look at my comment history, including in the last few days, you'll see that I dislike Git and think there are better alternatives.
The issue is: Once a gap has been identified, and there is plenty of documentation/resources out there, why is it not enough to point them to it? Why is it not enough to have a Wiki page listing all the tools they're expected to know/learn, with guides to resources to learn from? If there's a specific, obscure or internal tool with poor docs, I can understand spending time with each hire. But should a developer always teach:
- How to use Git
- How to write makefiles[1]
- How to do regular expressions (including teaching the syntax, etc).
- How to use a standard shell (bash/zsh/csh/tcsh)
Larger companies often have senior folks teaching courses on these, which I like. My complaint isn't that these courses shouldn't exist. It's that with some employees, directing them to the course simply doesn't seem to suffice.
I think the role of mentorship by senior folks is more for :
- Teaching them certain design principles/patterns
- Pointing things out during code reviews
- Teaching how to test things well (I still haven't found a single good resource for this).
- Teaching when to shun/embrace complexity
- What they should learn/focus on (e.g. identify strengths and weaknesses, and how to overcome weaknesses).
And so on: Basically things that are mostly gained out of hard experience or that are undecided (i.e. differing opinions in industry - senior giving his/her take).
But certainly, if there were books/resources that unambiguously teach items from the above, I think a junior employee should be given that resource and they should learn.
(And by learn, I mean on the job, on company time).
[1] Although I'd used makefiles to compile tools for over a decade, I never learned the syntax. Then for one job I needed it. No one would teach me it. It's a heavily used tool and it was understood that I should just read the Make docs. I didn't think it unreasonable.
-
If you have a good relationship with your boss, talk to them. Don't whine. Have a solution or a fact finding plan.
Why are they coming to you? How is that expectation being set and reinforced? I don't know how many people this is, or how big the entire org is, maybe you need an org-wide bootcamp. If they don't have basic reading and internet searching skills, how did they get the job? I smell something for management to handle here.
Yes, I was in an "agile" org that over-hired senior engineers and then expected them to just do regular "spade" work tickets.. but more quickly / more per sprint. No ownership of long running projects/tasks, no design/planning, just a constant stream of whatever ticket is at the top of the queue - GO.
Over the last 12 months, 55% of seniors have left. Most that remain have been at the firm 0-1 year..
The median senior now has 1 year on the team versus previous median of 3 years.
There's basically no institutional knowledge on the team anymore. Managers have now convinced themselves that all these green engineers are going to build v2.0.. however they are basically recommitting all the mistakes and suffering all the pitfalls that v1.0 did because.. no one is left to ask..
I just want to know how do you keep a job as a manager when you fuck up so badly. The vast majority of what seniors bring to the table is experience. That is also what you pay for. That experience is not like gold, it's like a gold mine - you have to mine it first, then bring it to the surface and only then you can profit off it. The fact that there are software houses out there that do not understand this is amazing (in a bad way). I mean I guess there is some value in a senior dev coding menial tasks (generally more mature, less error prone code with the right amount of abstractions), but that like saying there is some value in a rocket engine pulling a plough... technically true, but not really economical and there's a pretty good chance of most of your rocket engines going away rather quickly.
> My current manager decided to add 50 outsourced engineers to a team of 5 to deliver the product in a year (instead of the 1.5 - 2 originally guesstimated).
What one developer can do in a week - two developers can do in two weeks!
It sounds like you're not having enough coordination meetings. You can make communication more efficient if you add more levels of hierarchy. MBAs are good at managing. Engineers are often wandering off-topic, so put MBAs in between the engineers to manage the communication and avoid unsupervised engineer-engineer-contact between different groups.
Companies and entire markets follow similar patterns of only having bounded rationality, IMHO. Markets can also have decades of slack or delay from stimulus to outcomes. Take the slow decline of Boeing after acquiring McDonnell Douglas and their MBA heavy structure. https://qz.com/1776080/how-the-mcdonnell-douglas-boeing-merg...
How else will we justify the military grade, globally distributed, multi-planetary federated, immediately consistent Kafka cluster that the CIO just purchased? I’m still not sure how to get all the servers to synchronize when Mars is on the opposite side of the sun.
Make sure to deploy your micro services in Microsoft Azure AKS to improve the reliability on the long term, thanks to the included and frequent network issues.
There hasn't been a single job where I didn't have to explain Git to someone. Or that Git is not GitHub.
Wherever I was somehow in charge of some authentication / account management (never been my primary responsibility, but "people who know cloud" teams often get that honor anyway) I have always had someone who didn't understand MFA. Either they assumed because MS Authenticator sends them a push, AWS should send them a push or they would have a clock desynced so hard that the most generous TOTP grace windows couldn't save them.
My partner is in a place right now that had to be introduced to python dependency management. Really. No containers or anything like that either. Just alternate runing the script and installing the latest of a package until the import errors disappear.
I really don't mind tutoring, but many of these people also would rather wait 20 minutes for you to respond than 5 minutes on Google. Or even your internal documentation. That's linked in the Slack channel they're asking. It drives me nuts people value their peers time so little.
An interesting sociological question arises about how knowledge is passed down through generations.
One could count the number of software engineering management tenets on one hand. One of them was detailed in a popular book almost a half century ago.
If managers haven’t heard of the Mythical Man Month, how can one have any confidence at all about any of their decisions. Is management a knowledge-free profession?
I knew a CEO that claimed that Mythical Man Month was his favourite book.
As soon as it was decided the team was late (due to constantly changing scope) he put forth a plan to make the team 4x bigger in one year. Contrary to probably the most obvious lesson from the book.
People just don't read. Or admit THEY are at fault.
They'd probably fail to see the correlation in having their senior ICs occupied re-explaining Git to a constantly rotating offshore roster -- they're getting 10 engineers for the price of 1 after all.
As someone who interfaces deeply with Git on a daily basis, please don't imply that it's trivial or simple. There are a million edge cases you can get into, and people with 7 YOE on my team are regularly surprised by the facts we uncover.
Yes, git can be complex. It's also a requirement for modern software development. It is well documented, and not esoteric.
If someone hasn't taken the time to learn the tools their team uses, they will be a burden to the rest of the team. They don't need to become an expert, just experienced enough so they don't cause problems for others on the team.
I've never seen documentation on Git that was good and accurate. Pretty much every explainer out there commits major errors, claiming things like: commits are changesets, branches are sets of commits, claiming that any Git operation can be undone, implying merge is a symmetrical operation, or saying to never force push.
My company handles this by allowing them to study on the dime. I just ask how much time they want and ask them to do it, and if they need some material or help devising a study plan.
Curiously the two that needed it didn't really want to study at all, and we eventually let them go (they were interns).
Git command UI sucks (compared to some alternatives to SVN, HG, ...).... I'm not teaching that to other people except bare minimum. I will gladly explain advanced stuff, but they need to grok the basic themselves...
Some managers do that kind of things to prepare the next step of their career or because they worked for the company they are hiring (which is a variation of the first point.)
Most of these, I think, relate to a single kinda-meta-problem.
Managing software orgs is hard, and most orgs can't do it well. Using additional management methods, more managers, and more engineers can make the software org less efficient. Software production is weird. Efficiency of software orgs is extremely plastic. An effective 15 person team can outperform a 150 person team and this is normal. Very extreme compared to most fields employing such numbers. Software can be really important & high value. Value can be utterly disconnected from the cost of producing it.
I say "less efficient" purposely rather than "worse." It might actually make sense to go from an efficient 25 person team to an inefficient 500 person team. The additional cost of might be dwarfed by the benefits of marginally more higher output. That might be better economically (even socially), but less efficient.
If you're in one of these orgs, you will not be more happy though. Efficiency feels good. Inefficiency feels bad.
> If you're in one of these orgs, you will not be more happy though. Efficiency feels good. Inefficiency feels bad.
I think there's a sweet spot that's particular to each project and collective skill set. Being in a small team and feeling anxious due being responsible for way too much stuff isn't fun as well.
If you're in one of these too-small-high-pressure teams, and then all these extra "resources" get poured in... It can go quite badly too. IMO, engineers themselves are sometimes responsible by leaning on "we need more resources."
True. In some cases it can also mean that the team needs to limit the scope and focus on what really matters.
Sure, there's lots of startups burning the midnight oil to finish that MVP. But especially on more mature teams, it's incredibly easy to lose focus when doing software and spend several days on shitty features that don't really matter at all to customers, but are being prioritised due to inertia or capricious management.
Yap, I’m leading a project that could use more engineers (just two of us) cuz it’s going to be tight to hit an upcoming scaling deadline. But the thought of spending my time ramping up other engineers at this point doesn’t sound good.
This sounds like a variation of Brooks's Law - adding people to a late software project makes it later. In this case, now you need to take time to help the new resources ramp up, and the new resources themselves can't make meaningful contributions right away. So the pressure isn't alleviated for a while, and in fact goes up.
Same thing happening at the small team I am part of, we have just hired a fifth engineer, while the business often struggles to define what’s a priority.
This is a great point. I've never thought about it in these terms before, but whenever I've transitioned from organisations that feel like they're "run by engineers" into organisations that feel like they're "run by administrators" I've taken a hit in happiness.
> An effective 15 person team can outperform a 150 person team
Which is subtly different than saying a 15 person team can do the same job as a 150 person team. The full story is the first 15 people (be they developer or project managers) will determine whether you need 150 people in the future.
Naturally, all of my jobs have been at 150 companies (since that's where most of the jobs are), places where the earlier developers and PMs have balloon the amount of work to be done is a very unhealthy and inefficient way. Then I'm hired and continue to do the same.
I learned about R0 ("r not") in the pandemic, the number of other people someone infects on average, and I've imagined a "W0" at my jobs. How much work does a developer, on average, add or remove from the future of the company? Unfortunately, I believe I am a >1 W0 developer in my current job, my current work will only create more work in the future, and the company will have to hire more and more developers forever. I don't consider this my fault, but the fault of project management. It's also why I'm not worry about future job security.
People who want to be managers tend to create solutions where you need to assign more reports to them. I don't think this is incompetence, it is a reasonable way to advance your career at the expense of the company, similar to how engineers tend to choose frameworks that helps their careers etc.
> If you're in one of these orgs, you will not be more happy though. Efficiency feels good. Inefficiency feels bad.
Depending on your outlook, character and experiences, the magnitude of the results can make it worth your while; there's certain objectives that you can't hit without massive throughput (and waste). And reducing or keeping under control the amount of waste in a large scale project can also be incredibly satisfying.
> Efficiency of software orgs is extremely plastic. An effective 15 person team can outperform a 150 person team and this is normal.
"Software is eating the world", but most companies where software is either the product or a central part of the strategy (as opposed to a cost center) are still managed by people who either don't understand, or refuse to accept, that software is primarily _creative_ work, with a strong _collaborative_ component. In an attempt to reduce risk of an inherently risky creative endeavour, the management will over-hire and over-manage.
Biggest example is open-source: collaborative work done by random strangers on their own time and budget is competitive, and not rarely _way better_, than software produced by well-funded companies with competent people.
Like many engineers, the author of this article assumes all engineers are ethical, and perfectly suited to the assigned task. The author also assumes unlimited budgets, perfect control over a company's hiring and resource management, and a perfect understanding of the software's requirements.
These are the same complaints I hear from inexperienced engineers over and over and over again – and not just engineers, but anyone primarily responsible for 'labor' vs. 'management'.
The 'best engineers' empathize with the perspective of 'management,' that running a company is probabilistic, and that managers, co-workers, and other departments – like finance, recruiting, product, and marketing – are also duty bound by challenging constraints often beyond their control.
Maybe it's because I've always straddled the line between IC, EM and leadership roles, but in my mind engineers are managers. They are managers of software systems. The software systems are producing some economic output just as human or animal labor does in other domains or historical contexts. When you write code and deploy it to a production system, you are responsible for the behavior, cost and other implications of doing so.
Although I believe managing people is generally the harder of the two overall, managing software systems is uniquely demanding of being able to zoom into deep technical details and then back out to understand the big-picture implications and where different layers of abstraction may have failed. To call oneself a senior software engineer I believe you need both the technical understanding as well as the big picture view of what business value your code produces.
Many software engineers don't want to think that way; they look to the Product Manager to tell them what to build, the QA Analyst to sign off on releases, the Ops Engineer to tell them what broke, and the Engineering Manager to prioritize their time. And of course those asks do align with the job descriptions and are not wrong per se. The problem is that the SWE is in a much better position to foresee the majority of problems, and can save the company as well as their team a tremendous amount of pain by trying on different hats and thinking at a higher level. Not all company cultures make this possible, but IMHO it is the key to the highest performing teams.
This is usually why people make the distinction between “leadership” and “management” — if you use “management” the way your comment does, you no longer have a word for someone with multiple direct reports.
But yes — totally agree that “technical leadership” is 100% part of being a senior+ engineer and that almost always requires understanding the business and customers.
This article could be a parody with how shockingly naive it is.
The purpose of work is to solve business problems, not personal amusement and self-actualization. Business problems exist in the real world and have significant constraints. Many people will be much happier if they understood this.
I think the point here may be that when you’re dealing with an occupation in which the best engineers can pick and chose. Then you’re likely to lose your best engineers unless you’re exceptionally good at managing them. Especially if you introduce boundaries and restraints.
I’m not sure it’s naive to view the world like the author does. I’ve worked both sides of the fence, and while I’m now back in software development I do see the appreciation for my experience with creating the most business value out of your resources that managers come with. The thing is, though, if I don’t have to work in a place with too much bureaucracy or too many constraints then I’m not going to do so. I obviously try not to be an asshole about it. I don’t follow the company dress code in the basement troll factory where they placed IT, but I do have a suit at work that I can change into whenever I leave the “cave”. Those sort of things, so naturally I’ll play a long way in regards to what management want, but I’m never going to do estimates by the hour until the job market actively forces me to do so. Which likely won’t be in our lifetime. So when/if management go down the route of treating Software Development like they treat any other department (which like you state also are under significant constraint) then the company is just very likely to lose their most talented developers very quickly. I suspect that it would be (and probably is) exactly like that in any department, it’s just easier to get away with in engineering because we’re privileged enough to be able to leave our jobs today and have another good job by tomorrow.
Sorta. I would take a less-qualified but more personable engineer over their more capable peer any day of the week, for the aforementioned reasons: engineering isn't the only skill required – those who don't insist on managerial perfection don't actually need a lot of managing as a result. It's a positive feedback loop.
Also if engineers think we don't check references and backgrounds anymore – including reputation – those days are long past. It's too much of a liability to have the 'talented asshole' as part of a team anymore.
> Especially if you introduce boundaries and restraints.
Boundaries and restraints are a professional reality.
> So when/if management go down the route of treating Software Development like they treat any other department.
It's this exceptionalism that earns engineers the reputation of being jerks, and creates a negative feedback loop. Want to be free and clear to operate without too much bureaucracy? Play the cooperation game. This is as true with engineering as it is literally any other thing that requires more than one human.
You're doing a lot of assuming that the engineer seeking greener pastures because they are, I don't know "selfish" or something, is easily detectible. I can confidently tell you that you're operating under self delusion.
Also assuming that someone who isn't going to tolerate fuck-fuck games with assholes when they don't have to is themselves an asshole. It's entirely possible to amicably end a relationship with someone (a business) you can't stand, with them none the wiser that it was ever about something other than compensation.
> Want to be free and clear to operate without too much bureaucracy? Play the cooperation game. This is as true with engineering as it is literally any other thing that requires more than one human.
This is pure hopium. Bureaucracy is installed in anticipation of growth/security/safety gains, and existing success of the team can be completely ignored by someone who thinks the good of bureaucracy will outweigh the harm.
> I can confidently tell you that you're operating under self delusion.
Confidently incorrect! It's the iron law of the market; I don't make the rules.
Fwiw, bureaucracy used to not be such a pejorative term; it implies coordination at scale, with internal checks and balances. Engineering doesn't happen without talent, talent needs money, money comes from good sales and marketing, etc.
To be efficient, these things have to be centrally coordinated by an entity that typically has an eye on the market, which behaves beyond anyone's control.
What makes you think that the personable engineers aren’t also the ones leaving?
One of the reasons I have a lot of job offers isn’t that I’m the best technical engineer you’re going to meet, it’s that I have a large network and is generally seen as a nice person to work with. Obviously my ability also plays into this, but you can be both good at your job and a decent person at the same time. In my experience most people are.
> Play the cooperation game.
Like I said in my original post, I do this, and in my personal opinion experience so so most people. The thing is though, I have a lot of experience (and education) with/in the “MBA” side of things, and a lot of the things you see some companies do, that this article also touches on, like putting up a needless bureaucracy around estimates and time tracking, don’t actually work as intended. Time tracking tends to lead to cultures where the speed of delivery becomes more important than the quality, and estimating things by the hour is frankly just impossible in a field where you can spend an hour on something incredibly stupid and then 10 minutes on some brilliant solution to an issue marked as complex. I mean, maybe my anecdotal experience is from a mediocre perspective, but even after decades of programming I still do the equivalent of talking to a rubber duck, or at least asking my very good friend and coworker to come and spend 5 seconds spotting where I’ve made the obvious mistake (and the other way around), which we have time to do because we’re not on the clock to deliver as fast as possible by the way.
In a world of a lot of shitty business practices, people who can, will take their cooperation game to the place it makes the most sense for them. Including when they are also very personable people.
I'd say the more personable engineer is the more qualified engineer even if their technical knowledge is less. Being able to deal with other people is a massive part of being good at the job.
That is just an opinion and not a statement of fact. There are many different types of people and not all people have the same motivation. A lot of people care quite a lot about amusement and self-actualization at work. What a business owner might want does not change that.
(and let's face it, there are many many business owners who care way less about business problems being solved than they care about "being the boss")
> What a business owner might want does not change that
A business owner decides what the purpose of the business is, and what constitutes useful "work" within that context. If I'm hired to do x,y and z and I decide my motivation is rather to surf the web all day or spend all my time on personal projects, that doesn't change the purpose of work, it just means I'm not working.
Yeah, but if a business owner decides “x” is the purpose of work, and literally no one wants to do that because of the conditions that the business owner has created (especially if the conditions are tangential to x), then that is the business owner’s problem, not the employees problem.
There are so many actors and groups and dynamics and forces in effect in the relations that we commonly call "work", that trying to reduce it to a single purpose is laughably naïve.
Are you a people manager? If so, what is the turnover like on your team? I ask because the author is dead on and I've been in this industry for 10 years.
If you wanna make this a competition I've been in the industry for 16 years.
I'm a technical lead which does have a little bit of people management responsibilities. Turnover on my team is probably well below average, we had two developers leave for other jobs in the last year out of 15 developers and one fired for poor performance. I can't remember anyone leaving the year before.
To be clear, I don't think this article is wrong per se, just obnoxiously naive and doesn't have any empathy for the real world constraints that people have to work with. It's just... uhhh... rubs me the wrong way.
Tech leads don't have people management responsibilities. An engineering manager with your perspective would quickly find themselves without any talented developers. I did not write the OP but you're coming in with the hot take that it doesn't matter how people feel about their jobs and that is by the far least controversial part of the article and one that you're out of sync with 90% of the community on.
Agree re the article, disagree re labor vs management. This mentality in an org is almost always a result of mismanagement. The reason is obvious: it's a people issue and dealing with people issues is a managerial responsibility.
Thinking that managers are bad in general is only a sign of inexperience because it implies someone has never worked in a place with good management before. I've seen plenty of "fuck management" types completely chill out after moving to a better workplace.
Completely agree that it's on management to foster a great place to work. I put scare quotes around 'labor' and 'management' because they're really nonsense terms.
I'm a big believer of culture coming from the ground up; you can't design it, you can only help it grow with good soil, water, and food.
> The 'best engineers' empathize with the perspective of 'management,'
I deeply disagree with this argument of "empathizing": it is very often the case that if I tend to disagree with another side and nevertheless attempt to "empathize" with it, my disagreement turns into furious hate for the other side.
It is in my opinion often better for the peace not to think too much about the perspective of another side that you disagree with.
I'm not sure I would want to run a company without any gantt charts or deadlines. Management needs to know when a project becomes unmarketable or unsustainable so that project can be killed and resources moved to more viable projects. These decisions depend on variables that engineers can't see, though budgets and timelines are a few of them. Of course engineers can't take it personally when a project is killed either - some projects turn out that way. The best engineers know this. Your comment highlights well the narrow view of the subject article.
I'm sure we can all add plenty of fresh examples of bad organisational
dynamics. Other than texts like Gall's "Systemantics" is there an
equivalent to Acemoglu and Robinson's "Why Nations Fail" but for
companies and projects?
Here's some of mine:
Put "security" before all else. Pointlessly surveil and monitor your
staff for feelgood security theatre. Mandate MFA for every trivial
login so that simply checking your email becomes a tedious schlep.
Spam your employees. Send out daily self-congratulatory ego-trips as
"newsletters" celebrating how well the company is doing. Sap morale by
reminding every lowly engineer just how insignificant they are, what
huge profits the company is making and how much senior salaries
are. For bonus points use a "no-reply" internal address and make it
impossible to block them.
"Team build" by putting on mandatory "social" events, and various
awareness and training. Shame employees to do not "participate"
because that have actual work to do.
Keep zombie projects alive. Even though clients have cancelled and
everyone knows it will never be delivered, keep projects running for
the sake of appearances and to keep managers close to retirement in a
job for another year.
Actually, stop me! This could go on all day. Someone really should
write a book "How to kill a company".
The book would be an anthropological study. Having worked as a freelancer for more than 15 years, seen many companies from startups to large finance I see these patterns over and over again, it's like human nature.
Totally unrelated companies have these exact same flaws. Clueless middle management driven by money and ego making these destructive decisions. At the same time, a group of engineers at a startup without much management can go rogue and burn millions on fancy tech and frameworks without making anything useful.
The only successful projects I have seen is with a capable senior engineer in the team, who can listen and understand what a tradeoff is. If this senior is trusted by both the team and the manger the team can be effective.
Way too late in life I discovered what anthropologists actually do
after stumbling upon Alan McFarlane's lectures about "The origins of
Modernity" [1]. Nobody ever made history seem so interesting and clear
why What's Past Is Prologue. A big shout-out to all anthropologists!
I argue it's democracy. (That can save Nations and presumably companies)
Imagine voting for the CEO. Imagine voting to allocate budgets. Yes there will be a lot of pork barrel- but it might just work.
I mean the idea that companies are like single cells / autonoma so they don't have to be democratic leads us to silly ideas like trying to put in place rules for not abusing the electorate.
I mean if a boss is sexually harassing all the female staff and then asks for their vote at the next manager election, you won't need HR intervention to get rid of him.
I have no idea truly how this might work, but I do think that if the employees of a company voted how to run it you might find some unusual outcomes.
Maybe but that can also stifle innovation. If Netflix had been a democracy they likely wouldn’t have voted to switch to the unproven online streaming business, etc.
I mean that was what 2000? 2002? Peak dotcom time.
I don't agree with the decisions all these humans sometimes make (cough Brexit cough), but that's not the point - as long as we don't vote away democracy, as long as we trust the other side has everyone's best interests at heart, then we can manage
Don't forget management having engineers stop what they're doing to build elaborate dashboards to track OKRs, satisfaction metrics, whatever else, only to never look at it and only parade it around to other managers as a show of how in-tune with the product they're supposed to be.
Your list is more likely to contain your personal pet peeves - reasons you personally wouldn’t want to work in a company. There are plenty of people who’d say the absence of those things would be bad.
That highlights the real problem. Growing a company is very hard.
Security above output is a big deal. Put email behind the unreliable VPN on the magic corporate laptop of extra slow booting when we used to read it through an arbitrary web browser and revel in the increase in tail latency on replies. From minutes to days.
MFA for every login is a very good idea. If you're having to log in to the same service over and over again within a short amount of time, someone is doing something very wrong.
Sending out company newsletters seems like a nice way to let everyone know what the company is up to. Not sure how you go from that to reminding lowly engineers of their "insignificance".
Social events are a great way to get to know your coworkers and to improve cooperation. Awareness training (I'm imagining you mean things like Security Awareness and such) also seem like an overwhelmingly good thing.
Everyone has actual work to do. All the stuff you perceive as meta comes with the territory of working anywhere with a non-trivial number of people.
Does it even need saying? Of course there is. Many stories. Over many
decades. It's sad watching great people quit and wonderful projects
die because of a poor working environment and the selfishness of
others who inflict their narrow values in others. If you're one of the
people who see these as good things then naturally you'd frame
criticism as "bitterness". But as another commenter said, these are
personal stories. Your own subjective peeves might strike me as
strange. Do please open your mind to a world that contains different
people with different values.
> Sending out company newsletters seems like a nice way to let everyone know what the company is up to. Not sure how you go from that to reminding lowly engineers of their "insignificance".
Speaking as someone working in a small company that was acquired by a much larger corporation that shows all the signs being discussed here, it's not just newsletters. Those are useful. It's being sent dozens of spammy emails a week about initiatives that are clearly some VP's ego project and have no relevance you other than clogging your inbox and taking away some of your time and attention.
One recent example I got was three days of emails telling me to 'get ready' for an internal initiative but mentioning nothing else except a name. No links to click, no calls to action, no useful information at all. Only for the final email to reveal it was about a non-strategic initiative that applied to some other site only, despite all the emails being sent to the global company. All attempts at getting that sort of thing off the all-hands mailing list have been rejected.
A place that thinks that's okay does not respect the time or attention of its employees, and it does tend to make you feel reminded of your insignificance.
> Sending out company newsletters seems like a nice way to let everyone know what the company is up to. Not sure how you go from that to reminding lowly engineers of their "insignificance".
I agree with both you and parent.
I've enjoyed getting a monthly newsletter by email in past jobs, letting me know "hey so we just signed a contract with a client that is twice as big as the biggest one we've had so far". Makes sense - I'm not the one to be greatly inspired by something like that, but it's good for perspective.
I've also worked at a company where every single salesperson was allowed and encouraged to email all@company.com whenever they closed a sale. This was around 3 times a week.
Not terrible - however, everyone in the company was also officially encouraged to "congratulate" any such "successful sales" emails with "encouraging words" such as simply adding "Congrats!" and hitting "Reply All".
The head count at this company was around 400.
I wish I was kidding.
I think I lasted 3 days before I created a filter rule in my email client.
But looking back (I have left this company since then), I believe your strategy would have genuinely had a positive effect on any employee's career path.
"What makes engineers sad? Their boss(engineering managers, Directors, VP’s) do not know what they face on a day to day basis and does not know how to build something, whether it is a feature or architecting something from scratch."
If that's true, then it's probably mutual. Engineers typically do not realize that their manager's role is to manage people and process (which is a bit of a specialization in itself), and knowing how to build software is not necessary but definitely useful - mainly for questioning your engineers when they tell you something that sounds crazy.
If any engineers are under the impression that their job is harder or more important than management, sales, etc, they're being arrogant.
Coming from a former strong engineer who started a company and now manages people more than code.
There are different types of hard. Digging ditches is hard work, getting people to do what you want them to do is hard work, writing complex software is hard work. When engineers think about hard work they usually think about it being intellectually difficult. It isn't arrogance, more that they are just focusing on the definition of hard work that they are used to.
I disagreed with this point in the article. I do not need a manager that has done my job before or spends a week a quarter doing my job. I need a manager that knows how to get my team the resources it needs and knows how to to deliver a product. Most importantly, I need a manager that trusts the team.
I've had great managers that couldn't code their way out of a paper bag.
Yeah i agree and think it can even be phrased as just not micromanaging. You understand which resources benefit the team and delegate a certain amount of trust to trustworthy individuals. Then hold them accountable to that trust. Dont dump stuff on them and dont jerk the wheel. Share your constraints; etc. Learn who is good at leading, communicating, etc. Do skip level 1:1s to validate your assessments and understand boots on the ground.
I use to also think being technical was a part of that but now i think being a good manager is worth much more on its own.
But more importantly, it's impossible to manage a process that you don't know how to do yourself. The closest you can get is on a client-seller relationship.
I find that, in practice, the more a manager knows about how things are done - the more they have the urge to micromanage and resist delegation, especially if they're perfectionists.
Doesn't sound completely horrible in theory but in reality it's bad for everyone.
They manage a process they do understand (in theory): getting groups of people to do valuable stuff without irreparably imploding.
I don’t understand any of the tools I use in my own work (how does VS Code do syntax highlighting? How does the electricity make my laptop screen show me high resolution colors?). But I’m still able to produce plenty of value for my clients.
> Engineers typically do not realize that their manager's role is to manage people and process
In my experience, where ever engineers are not realizing that, it is when management is not managing process and people. Both management of process and of people are visible - when manager is doing it, engineers and know. But, fairly often management is preoccupied much more by activities directly visible to their bosses and and much less with those that can improve internal functioning of the team.
> and knowing how to build software is not necessary but definitely useful - mainly for questioning your engineers when they tell you something that sounds crazy.
If you are supposed to manage process, you need to know what engineers, testers, analysts, customer support do on daily basis. You dont need to be star, but you need to know where they spend time and what their issues are. Otherwise your process wont solve issues that are occurring in your team. You will be solving imaginary issues some other teams have you read about on the internet.
And the above is greatly frustrating for everyone under you.
By far the hardest part of that transition (at least for me!) is going from being able to create measurable impact on the order of days to most things taking months or years to create real change.
As a coder, I could get a bug report, build a fix, test it, get it deployed within an hour if it was urgent and simple.
Now I do a lot of listening, a little bit of talking, a bunch of thinking and discussing with the rest of the executive team, and mostly make small corrections which might show meaningful results in 6 months' time. Every so often there's still something really amazing and valuable, but it's much rarer and less predictable when that's going to be.
And yeah tons of new learning to do. Being a good programmer doesn't automatically translate to being good at running a company (though understanding tech and having been there certainly helps both for understanding what your staff are going through, and having their respect)
I strongly agree that managers do not need to be technical or understand dev work. However, I don't have much sympathy for managers who are "misunderstood" by engineers. Companies that have issues with disgruntled engineers grumbling about management and process are mismanaged almost by definition.
The underlying principle I've been using to understand this is, no engineer worth their salt will be spending a material amount of time working at an organization that they don't believe utilizes their talents well. The opportunity cost of talented software engineers is much too high in general.
This applies regardless of actual talent and does not guarantee results. I've seen mediocre SWEs with inflated egos jump around because they felt their "world class" talents weren't being put to good use, some unsuccessfully, but some rather successfully fooling their way through the ranks of management. But I've also (more frequently) seen disillusioned, extremely talented engineers leave an org that was paying them obscenely well already, but was making them feel like they were wasting their time, for a shot at a startup dice roll which does not pay off as well (on average).
This would only be true if finding another job was a simple (and reliable) process for most people. I imagine you might come back and say, "But finding another job should be easy for a talented engineer!" To which I would say, nope! Not true! The tech interview grind is often inconsistent and demoralizing. Even talented people might make a reasonable calculation to avoid the trouble and just stick with their current job.
Correct. People also assume that you’re always going to get paid more at a new gig. This just isn’t true in SV. If you joined a startup and it rocketships - I’ve seen many smart engineers stick around for years just because they have a 7-fig TC. Why would they move elsewhere? Just isn’t financially responsible and most are willing to suffer through it as far as I’ve seen.
> no engineer worth their salt will be spending a material amount of time working at an organization that they don't believe utilizes their talents well
So is everyone developing advertising at google is a second rate engineer?
I think believes is the key here. There are definitely people who believe that if they can work on complex graph colouring problem in a real-time processing scenario and the interruptions are minimal - then indeed their talent is utilised well. And I can imagine such a scenario happening at Google in advertising department/division/tribe .
There are plenty of critical, unglamorous jobs which need to be done. It’s not unreasonable for an engineer to value high six figure/seven figure salaries over a feeling of work fulfillment and skill utilization
Agree on some points (first 3 for sure), disagree on others.
A major missing one is the demoralizing effect of having to work with incompetent team members, with management unwilling or unable to do anything about it.
An incompetent person is likely not a bad person - more likely a good person who is the wrong position, or who just isn't capable.
I recall working on a team where I was called over by one of the members to help out. I was new on the team, and wondered what the sidelong looks from other team members were about. She wanted to know why her program did not run. I asked to see the compiler output. She asked what a compiler was. How a person could attain a masters degree without actually knowing that is beyond me, but her skillset clearly had nothing to do with software.
This was in a government agency, so she was promoted to management where she became one of those other problems on the list.
> How a person could attain a masters degree without actually knowing that is beyond me, but her skillset clearly had nothing to do with software.
I've worked with a few PhD's whose software engineering experience was limited to Matlab scripting. One even refused technical training because that's "not what they're interested in". Another co-worker with a masters still had no idea what they were doing after 4 years working there, often asking the same basic questions at a few weeks interval. Stuff like which branches to merge in a PR or questions that are answered verbatim in a readme file.
Having to babysit educated people who refuse or are unable to learn is a great way to get demotivated. When those people start getting promoted to management positions and training junior employees is when things really start to derail.
I'm glad you said that this was at a government agency otherwise I would have been sure that we worked together in the same team, with the same person.
I worked together for a year with A. who is a "senior" engineer, some of the stuff that A. pulled was;
- Not being able to use GIT. At some point we decided that I would have to do all merges because he just wasn't capable of doing them.
- Editing the project using nano on a server because he couldn't figure out how to install GIT on his laptop. This included YAML files where he would manually count the indentation...
- Reviewing the old code in a pull-request, multiple times...
- Copying the requirements from project A to unrelated
project B because they're both Python projects so it should work?
- Claiming to be able to program in multiple languages, giving examples such as INI, YAML and JSON...
- Claiming expert knowledge in C++ and Java, I haven't seen him read or write a single line in all the time that we worked together.
- Sending endless questions over Slack about the most basic things that he could figure out himself (e.g did you look at that PR? When I had already approved and merged it or how do I change something using SQL?)
- In general just not getting anything done, there was one sprint in which he finished two tasks, one of which was changing a password in a text file
After a while he was made temporary lead and the following happend;
- Killed my CI/CD pipeline because "automation is dangerous", manual releases now routinely take over 12 hours...
- Introduced a rule that PRs now had to include screenshots of manual tests instead of us writing automated tests
- Lying to stakeholders about issues, literally: "we can just claim it was a bug in vendor X code, it will look better!"
- Proposing to re-review old PRs every two weeks, because PRs are like fine wine?
- Giving tasks to the team that made no sense. E.g a task to
clean-up old versions of software X that was upgraded using YUM on a Linux server. I tried to raise the point that the package already included a clean-up script. He got angry and didn't want to hear it, I chilled for a day and closed the ticket.
- Insisting that production password would be encrypted on disk (granted, not the worst idea!) just to proceed with then storing the plain-text password on Confluence (where it was accessible to the whole company) and in GIT :)
- Killing our database replica's because: "they were misconfigured, someone linked them to the production database. That's very dangerous!"
I documented and raised these issues with my manager who didn't want to address them because: "it would be bad for A. motivation". I said screw this, I can't work like this and stopped working with him on that specific project. Productivity dropped 80%.
He's currently scheduled for a promotion to "tech-lead" at the end of the year. I've left that place, some places are just not worth saving.
> Stop estimating. I have analysed every team I have been on that use estimation. Those teams have been 99% incorrect. In my experience, it does not work. If you need dates, I would recommend a more modern approach like forecasting.
What's the difference between estimating and forecasting? Seems very binary as written, but at some point don't you have to look forward and make some assumptions on complexity/effort required to solve a problem and the general time it takes to solve them in order to do a forecast?
Don’t you still have to correctly estimate the amount of work (time) to complete each task in your backlog?
You can apply all the “science” you want, but at the bottom of it all you have engineers holding up a card with a “4” on it when the scrum dude says “add date picker to the Foo widget.”
When I did this last, we incorporated size of epic instead and looked at number of tickets on average. You still have to break it down but you can take into account the number of added tickets given a large enough sample size.
You still need story point estimates on the previous items, or some reason to believe that previous stories were of similar size (which is also a form of estimate).
This sounds like it's written by someone who's only been in teams that do point estimations. Those are, almost by definition, 100 % incorrect because even small variations mean you're not done exactly when you said you'd be done.
If you estimate in properly calibrated 90 % intervals, you'll be correct 90 % of the time, and this is something you can verify continually.
My company right now does OKRs with priority levels for each task. If you make it a P0 then you're saying it will get done this quarter baring really unexpected circumstances (ie: shit happens, we understand). P1 may not get done. P2 is even less likely to get done. This creates a natural distribution by holding the date constant and varying the work done by that date. Personally I find this more reliable and easier to communicate than holding the work constant and varying the date of each item.
To be honest, I also like that approach better, because in my experience the budget tends to be relatively fixed, but the work amount is often fairly flexible.
A good reference is Douglas Hubbard's How to Measure Anything. The idea is that most people can calibrate their sense of probability to be fairly accurate, by intentionally adjusting for some common biases. (In particular, if you prevent anchoring and availability bias, and actively engage system 2 and your loss aversion, you get a long way. There are specific techniques to do that in the book.)
This is really easy to practise and test too, since all you need are a bunch of questions where the answer is known, but you are uncertain of it. Then you can guess a range in which you are 90 % certain the true answer lies, and after 10 such questions, you should be correct roughly 9 times.
Points are a way to do this, but I prefer engineers who are calibrated. It's very powerful to ask someone for a calendar day when something will be done (or really just about any other question about anything), and be able to be reasonably confident in the span they respond with.
I’m a developer who’s been doing this for a loooong time and I can’t imagine being able to accurately guess with 90% confidence the calendar day I’ll have a particular task done. And the tasks I work on are different enough that a feedback loop about how much I misguessed would be useless for error-correcting future estimates. Maybe that works for factory-like tasks like how long it tasks to add a REST endpoint for a CRUD action?
No, it works for anything. The key that people misunderstand is that if the task is really uncertain, you're allowed to give a really wide range. In fact, you're supposed to -- that's the only way you can be correct 90 % of the time.
As a concrete example, I recently estimated "somewhere between 1 week and 4 months" when asked about an semi-well specified feature because I felt there's a 5 % chance it's done in less than a week, but even under pessimistic assumptions, there's about a 5 % risk it takes longer than 4 months.
When asked about a larger, unspecified projects a few years ago, I didn't hesitate to respond "between three months and 15 years". Sometimes that's the best you can do due to the uncertainties involved. It sounds useless, but it's really useful to have a quantitative measure of the uncertainty.
Technically-proficient managers (that are also good managers). The combination of those two is rare.
Management is often considered an "ego position," so unqualified* people fight to be managers. It's not always about the money. It may be about the office, the car, the administrative assistant, the invitations to trade shows, etc.
Also, upper management types frequently consider "workers" to be "lower class people," and only want people they can relate to, personally, and that don't make them uncomfortable, in management roles, so they end up mining the Yes Man and Politician veins for managerial talent.
In my case, my company actively discouraged me from being technically proficient. They would routinely deny me training (so I went to training seminars on my own dime, and took vacation time), and would ignore my technical work (which was often extremely relevant and useful). I ended up doing a ton of open-source work, just to keep my tech chops up. Because it was my own work, I did stuff that had very little connection with my "day job," and also brought my own equipment.
I hated being a manager. It was always a burden, but I feel (and everyone else seemed to agree), that I was pretty good at it. Since leaving my last job, I ran screaming for my tech work.
*"Unqualified" is not just "technically unqualified," but also "emotionally unqualified." I think managers need to remember that they are managing people, not just "human capital," and that, if things are done right, their employees may be more technically qualified than they are. That was certainly the case for me, and I was proud that my team knew more about the work than I did.
So I guess this post is only for big companies and VC-funded startups. I'm the technical cofounder of a tiny bootstrapped company, and for now, I'm the only engineer. Being the sole engineer is stressful, but it's currently necessary, and I think it's worthwhile to maintain the control and integrity that we'd probably have to give up if we pursued the funding to hire a bigger team. Even when we do have the revenue to hire, we will certainly not go straight to a team of 6 or more engineers. Big teams have their own problems, like communication overhead.
When you're have a small company you're hoping to turn into a larger one, many deadlines are every bit as existential as a DoD proposal deadline for a defense contractor. Especially when you don't have a big slosh pool of VC funding (but this is largely true even if you do), the difference between "stable and growing at a healthy pace" and "if something doesn't change we'll have to shut down" is often one or two customers.
This is only a feasible plan for people without any children or committed relationships though. Telling your spouse that you'll skip the vacation because work is more important than them will not go over well, for obvious reasons.
I work in a small company, and we have a team of 3, if you count liberally. One colleague does front-end stuff, there is a tester who is intimately familiar with the way the software is used, I do the rest. That's really enough for the moment.
Agreed. Teams that are any bigger than that inevitably run into communication problems. Small teams are good for close cooperation. Big teams are good for wasting time.
Granted, speaking as someone running a very small shop, mostly freelance, I really think a lot of the ennui and sense of being overwhelmed or unsatisfied can be solved by just deploying constantly. Rather than get stuck in a review cycle I try to get every incremental change online as soon as it's done and minimally tested. That can be up to six live redeployments per day, especially when a new feature is in beta. It's however many redeployments are needed when something launches. I prefer a local test server and straight to production. When you get the third build of the day uploaded by 5pm, and hold your breath til 6pm without anything catastrophic happening, you can keep your phone on and go get some beer and fajitas. If you make it to 8pm and the company is still running, a deep sense of fulfillment sets in about a job well done. That feeling of the day's work being done just doesn't exist unless you break it up into tiny incremental updates.
It astounds me how some companies will let months of work sit in an unmerged PR and then sometimes decide they don't even want it. Not only is it a massive waste of resources, its shit for the person who built it, and also sucks if you actually do have to merge it and resolve months of merge conflicts.
There's the burnout from being overworked and then there's the burnout from nothing being done.
This is why I'm always ringing the trunk based development bell. Get crap into the mainline now so we can understand it today and start fixing it.
Nevermind unmerged PRs. I've known engineers who spent years on a product only to have it canned when completed due to political reasons. They all left soon after, quite understandably.
On the issue of estimation, you want to drill down to:
1. Why are you asking? and
2. What happens if I'm wrong?
I subscribe to the view that you can either launch based on features or launch based on time. You cannot do both. If your product is a compiler and you want to support, say, ARM and that requires a bunch of work, you have to choose to release a version at a particular time or to launch with that feature complete. Many people just don't get this.
You can try and hit a time goal by resourcing but this is often done in a counterproductive way eg by throwing bodies at the problem when it's far too late and as we know that can just slow down the process as the people who know what they're doing have to ramp up the people who don't.
Often you're being asked for an estimate because management wants to ignore this and is fine with forcing their team into "crunch time" to meet some arbitrary goal.
As for what happens if I'm wrong with an estimate, basically am I going to get "punished" for underestimating? Be that through getting a bad performance review, a lower bonus, a lower stock grant or whatever.
If so, you've just created an incentive structure for me to completely overestimate because there's typically zero benefit in overdelivering (other than a perfunctory "ata boy"). So if I think something will take a day, I'll end up estimating 1 week, maybe even 2.
You should build some buffer into any estimate but if you are punished for taking longer and not rewarded for being faster, what do you think is going to happen?
Now you might have a bug to fix a typo on a website and if you say that'll take a month obviously that won't fly but a team will generally settle on estimates that are really large without being large enough to draw scrutiny.
Even then, many managers will take an estimate of 6 days and negotiate down to 3 days without knowing what went into that estimate. That too will lead to buffers being padded.
If someone takes longer through no fault of your own (eg it just turns out to be really complicated in a way you couldn't anticipate) then I've seen it more than once where a manager will throw that engineer under the bus to save their butt from their own management.
In short, estimates are an almost sure-fire way to create an adversarial environment between engineers and their direct management.
Agree with most points but one which is making a manager do coding/shipping.
Most of IT managers I met possessed no real IT skills. They wrapped their heads around only as much theory as needed to _manage_. Most of them did not came from engineering world but from business one.
Ideally, manager should be able to do the work their team is doing, but reality is quite different. I stopped expecting managers to understand what I do outside of expected effects.
Regarding estimates, it really is frustrating when a non-technical manager cannot understand the inability to state any reasonable time estimation.
- so how long will it take you to finish this task?
- no idea, haven't done anything like that in the past
I think the mismatch is partly that your early experiences (family, teachers, and team leads) are with leaders who literally know more than you about most topics and could do any task they’re asking you to do. That imprinting is strong.
Then, when you get to interact with Directors and VPs who have teams across 5-20 disciplines and the senior leader could be an expert in a maximum of one of them, you start to question why this person can’t do your job and therefore think, they must be an idiot.
They might be, but it’s more likely they’re past the point where they are more subject matter expert in the field than the people they lead.
- Manager: How long would it take to migrate from A to let's say B?
- Me: How would I know that?
- Manager: Just make an educated guess.
- Me: Maybe X months? I really don't know.
- Manager writes down X.
- Me makes a mental note to not trust Manager again...
Maybe it's better to have any plan than to have no plan, but having a plan based on known bad data can't be the solution.
Dear Managers, if your plan requires data that just isn't available, please take the time to ask yoursevles if you are micromanaging. Going with a less concrete plan is definitely better than going with a plan based on wrong assumptions! Maybe you are in a position where deadlines just make no sense and you need to be more agile?
- Manager: How long would it take to migrate from A to let's say B?
- Me: What do we want to accomplish from the migration? I'm assuming cost reduction?
- Manager: Yeah, the guys at B are much cheaper.
- Me: Ok, give me until EOD Friday to do some investigation.
- Manager: EOD Thursday would be better, don't need a full roadmap, just enough for an ROI. I'll flip over the CEO's spreadsheet that she's using for the calculation.
- Me: This means Feature X is dropping from this sprint.
- Manager: Yep.
Dear Mes: Grow up and participate in the process rather than starting off with snark.
Hah if only managers were that grown up too. I’ve tried those conversations.
Firstly, that Friday deadline likely would have been fine, it was just a power play.
Secondly, when the manager said “yep” to dropping the feature, you’ll still be expected to make progress. (Of course most of the time they try to make you do double the work. A quick “yep” wouldn’t happen IRL)
How many times did you take a task you have no idea of the timeframe, do some short research without completing it and was able to make a correct estimate?
If that happened even once, I would be interested to hear about it.
Literally all the time. Just had exactly this scenario with a technology switch. I spent an hour reviewing their api. We had a meeting with their sales engineer, I asked them a bunch of questions. Estimated 10-12 days to finish phase one integration, was working in single sprint. Larger projects get more upfront investigation and larger error ranges.
Most engineers can guestimate, but I do know one that would say the following:
no idea, I will have to do two days of research on the matter and come back to you with an estimate in standup the day after tomorrow. (really, he said exactly that one time, it was a wonderful expression of his character I thought)
The person who just says no idea, and doesn't have a way to get to an idea, seems to have a very problematic limitation.
It's not uncommon IME that doing the work to come up with a reasonable estimate is 80% of the final work.
E.g., addressing a scalability issue might require a bunch of profiling work, then a bunch of experimentation / thinking about developing a lock free algorithm. Or it might turn out that reducing false sharing a bit will give large enough benefit on its own. Without having done most of that I won't know whether it's a few days or many weeks.
>E.g., addressing a scalability issue might require a bunch of profiling work, then a bunch of experimentation / thinking about developing a lock free algorithm. Or it might turn out that reducing false sharing a bit will give large enough benefit on its own.
so this sounds like my example of my friend that I gave above who would say I will have to do a bunch of profiling work first and then a few days of investigation before I tell you how much it is actually going to take.
I don't say you can't run into uncertainties and be unable to estimate until you have clarified those uncertainties, I also don't say that you can't run into uncertainties in the actual implementation and have your estimate be woefully off, not every estimate needs to be correct.
> It's not uncommon IME that doing the work to come up with a reasonable estimate is 80% of the final work.
That estimate you do after finishing 80% of the work is probably orders of magnitude smaller than the real thing.
More realistically, if you don't have the experience for an estimate beforehand, you also don't have the experience to know when you covered enough of the high-risk subproblems, so you have no basis at all to decide how complete your research is. You will only have a reasonably safe estimate by the time you finish the task.
There's tasks where experience doesn't tell you ahead of time how long something takes. If you need to figure out a [novel take on an] algorithm, it'll be hard to predict the time even if you did things like that plenty times before. And you'll be able to judge the remaining work after pretty decently.
I don't agree with this. If an engineer can't estimate how long something will take, usually that's an indication that your requirements are unclear, or there's a history of changing up requirements on people. What you've labeled as a limitation is probably an engineer being honest with you.
ok so in this case I would probably expect them to say:
the requirements are unclear - that right there is them having an idea how they are going to be able to give you an estimate, by forcing you to be clear in your requirements. That would actually be an engineer being honest.
or
there is a history of changing up requirements on issues like this, I can give you the estimate of what it will be with the current requirements but if the requirements change, as in my experience they are likely to, then that estimate will have to change as well. - this would also be an engineer being honest.
Both of those honest examples aside if the engineer replies no I can't make an estimate and I never will be able to it is probably the engineer being a bit pissy. And I know definitely one or two guys who would exactly behave in this manner.
unless you are dealing with the first time implementation of something that there is only mathematical theory backing it and no previous implementations in the world, I have a hard time seeing how you can construct a situation in which an engineer cannot come with an estimate AND cannot find a way to figure out what they need to come with an estimate (more specific requirements, research on the matter). If they can't figure out at least one of those things I'm going to think it is probably a limitation on the part of that engineer.
Finally, I am an engineer. Although I tend to be one of those arrogant guestimaters, which is a failing in my personality.
> Regarding estimates, it really is frustrating when a non-engineering manager cannot understand the inability to state any reasonable time estimation.
On the flipside, it can be frustrating for managers that engineers sometimes can’t understand that they have to manage deadlines.
If the engineer doesn’t make an educated guess at the time it will take then the manager is put in the position of making a non-educated guess (because you can’t effectively run a company without having any idea of either time or cost to deliver).
The idea that it’s possible to have a project with no budget or time constraints just isn’t often the reality of the situation.
Imagine going to a customer and having to say “Ok, we’ve talked to the engineering team and in order to deliver that feature you asked for they might be able to deliver it in a day for £2,000 or in a year for £500,000”
This doesn’t mean that you can’t give sensical ranges, or state your assumptions when doing the estimate.
>The idea that it’s possible to have a project with no budget or time constraints just isn’t often the reality of the situation.
It must be possible because most budget and time estimates end up being way off anyway. Virtually no real projects are managed on the basis of accurate estimates of how long they'll take or how much they'll cost.
Time is almost always more flexible than the people imposing the deadlines think that it is.
As for budget, you just have to choose to keep spending more, or to stop (or wait till you run out of money). Making up an estimate beforehand doesn't alter that process.
If management were really in the business of setting budget and time constraints, projects would constantly be getting canceled because they went $100 over budget or a week over time. In reality we all know what usually happens: the project simply continues; the estimates, deadlines, etc. are shifted.
> It must be possible because most budget and time estimates end up being way off anyway. Virtually no real projects are managed on the basis of accurate estimates of how long they'll take or how much they'll cost.
Making decisions on the basis of an estimate which could be plus or minus 50% is fine.
It’s better than making a decision on the basis of nothing at all, and then managing the project with no clue about how long it should be taking or costing.
> If management were really in the business of setting budget and time constraints, projects would constantly be getting canceled because they went $100 over budget or a week over time.
This isn’t the idea of estimates - the main idea is so you can effectively allocate resource and understand cost/benefit. All companies have limited resources and must decide if they want to focus on feature A or feature B, and part of that decision will be the likely cost, risk, and timeline to deliver.
You aren’t going to cancel a project when it goes (a bit) over budget because the development costs to date are already sunk (ie you only now need to consider remaining development effort in the cost/benefits calc) and the benefits are probably still the same.
But most estimates are completely wrong (much worse than +/-50%). Only accurate estimates can possibly be useful for planning, and very few estimates of time and cost for software projects are accurate.
> Only accurate estimates can possibly be useful for planning
Nah, a best guess estimate is better than no estimate at all. If engineers don’t estimate it doesn't mean estimates go away, it just means they have moved responsibility of estimating away from the engineers to the management team (who will then need to make their own estimate of how difficult/expensive something is to do and how long it will take).
Besides, you can be accurate without being precise - and engineers can work to become more precice over time as they gain more experience.
>Nah, a best guess estimate is better than no estimate at all.
Only if it's more-or-less accurate on average. It can't possibly be the case that a highly inaccurate estimate is better than no estimate. If you don't know, you don't know, and you should plan on that basis, not on the basis of a made up estimate.
> On the flipside, it can be frustrating for managers that engineers sometimes can’t understand that they have to manage deadlines.
Deadlines are not solved by estimations. Deadlines are a business problem that can be resolved by a discussion with your engineer to work out a plan based on that time constraint. If you have a deadline in mind for a feature, it would be better to state it directly. Then the engineer can say it can or can't be done the way you wanted. Or we need to modify the requirements to fit it in this timeframe.
But the most horrendous thing I've seen is when you give an estimation, the manager treat it as an actual deadline. It should only be used to verify if everything is progressing correctly and should be revisited periodically. But not to make promises.
In those cases the correct answer is "Dunno, but I'll have an estimate by tomorrow after I do some prototyping".
Then you do the janky prototype and try to extrapolate how long will it take to finish it properly. Then double that and be the miracle worker who delivers in half the time :)
But do not under any circumstances be tempted to demonstrate said janky prototype, unless you want to get re-tasked while said janky prototype gets merged into the build because 'schedule' .. and then be haunted by the damned thing for at least the next three years
Yep, janky needs to look janky and be slow and break. Otherwise they'll think it already works :D
That's also why you always keep the UI on par with the backend as far as completion goes. If the UI looks complete -> people think the backend is complete too.
I know exactly what you're talking about. The first rule of the meeting is "shut up" and the second rule is "keep silent" and "watch your mouth". I don't know why it is so hard to stick to those simple rules when the solution to the engineering problem seems so obvious.
Nobody can work with engineers who are unwilling to commit to a schedule. Often it is very hard to make them commit and even if they do initially they often start missing deadline after deadline. A total nightmare for project management.
> Nobody can work with engineers who are unwilling to commit to a schedule. Often it is very hard to make them commit and even if they do initially they often start missing deadline after deadline.
So you're saying that 1) engineers have to be forced to "commit to a schedule" and b) that schedule then turns out to be fantasy.
I want you to think harder about what you said and where the problem actually lies. Maybe the engineers know something, about what's knowable upfront, that you don't.
True, the problem lies somewhere else. Maybe the project should not exist at all if it's not manageable.
The question "can you do it?" implies more than "can you maybe do it if you have infinite time and luck?" it implies "can you deliver on time?" and if you cannot then you should not take the project. The problem is that it's hard to hire engineers that are capable enough. Therefore we must make it work with the engineers we have and that means to push them harder than they are used to. If they succeed, then great.
> The question "can you do it?" implies more than "can you maybe do it if you have infinite time and luck?" it implies "can you deliver on time?
Incorrect, it implies "can you do it in a reasonable time, that is as yet unknown and unknowable" - which might even be quite small, but no-one really knows, so committing to a fixed deadline is at best fooling yourself, and is more likely a trap.
> is that it's hard to hire engineers that are capable enough. Therefore we must make it work with the engineers we have and that means to push them harder than they are used to. If they succeed, then great.
I think that problem is that this is an intentionally deceptive, demented burnout-factory, and no decent engineer would want to work for you.
How could you make project management plans that imply deadlines if you don't have deadlines?
Yeah, maybe it's not such a smart idea to start with commitments that imply dates. But that's how it is. If you want to work in your own way then start your own company, I guess. Maybe it's time to do that.
How well do the people executing the project know the codebase, data, and tech stack they're working with? How understood and confirmed are the requirements? The less those things are true, the less certain you can be with estimates. At the extreme, all you can do is poke the system and commit to providing feedback on what you've learned.
At the same time, you should be trying to make the system more lucid, both for yourself and new joiners on the team, such that estimates can become more accurate. The more senior you are as an engineer, the quicker you should be able to do that.
When I'm asked by my boss to estimate, I break it down for him. This part here I'm confident is 1-2 days of work, this part here can potentially be tricky so could be 1 day could be a week, and this part here I can't tell without digging into the details.
If this is based on a customer request I'll try to find some restrictions he could take back to the customer to narrow the scope and provide a better estimate assuming those restrictions.
What if he asks you for a number instead of a range? After all you have to use the company template to present your project and that does not have ranges on it.
If for example, I say 3-7 days and he wants a single number because customer wants a date, he'll ask me "ok, so if I say to the customer they'll get the change in 10 days, we should be able to deliver?"
Then I say yes, under the assumption of X, Y and Z that sounds realistic to me.
Of course, sometimes the numbers are to high. That's where narrowing the scope or even finding a different solution comes in.
We don't want to manage engineers we want to manage projects and projects have budgets and deadlines. If you can't deliver then maybe you're not a good enough for the job. If you can't even promise then why are you still working at our company? One of the best ways to drive away engineers is to make them commit and then watch them fall into misery when they desperately try to somehow make the deadline. Many weak characters break that way. The trick is to make them choose their own deadline and fail. That way you take away the scapegoat "they set unrealistic deadlines" because the engineer digged their own grave.
You write that you don't want to manage engineers?
But from what you write you cannot manage budgets and deadlines.
Managing budget and deadlines is not about setting some "ideal world" and then whipping these lazy engineers to deliver exactly that.
Managing budget and deadlines is about - well we delivered X/Y at that date it already was $yyy in terms of money. If it went well maybe you can increase work load, maybe look at things again and stop gold-plating to move further. If it went wrong cut the scope - check what went wrong, lower the risk of not delivering by simplifying tasks. Check if maybe you miss some specialistic knowledge to hire someone to help and account that risk against budget or tell customer that you need something specific that they have to deliver.
> If you can't deliver then maybe you're not a good enough for the job.
I've seen more than once projects with ill-equipped team members. I've been one myself, too.
Even in established tech corporations, the process of team creation can be screwed up due to multiple reasons. I've seen DevOps engineers tasked with writing apps because PM did not checked what their role was. And that was a high-importance project in a huge, publicly traded, tech corporation.
Expecting engineers to estimate work they haven't done before ends up in guesstimation which is almost never correct.
PMs asking for estimations in pioneer projects create problems for themself, which they sometimes later blame on team members.
They are asking because they have been asked themselves. To me it seems like a chain of incompetence from top to bottom, from bottom to top. Everyone is stretched beyond their abilities. The whole company is a house of cards. But yet it keeps on working and often it delivers results that keep everything else up and running. I don't understand why it works this way but it does.
The question is often 'how long does it take to implement'. Engineers know if it is more or less clear what the functional requirements.
In practice, workdays are constantly interrupted by meetings. An 8 hr workday is effectively 2-4hrs product building. Than there are unforseen deployment problems, some requirements change, solve merge conflicts, perform code reviews, frameworks need vulnerability updates, etc.
An experienced PM knows this and should not use implementation time as project duration.
> Many weak characters break that way. The trick is to make them choose their own deadline and fail. That way you take away the scapegoat "they set unrealistic deadlines" because the engineer digged their own grave.
> Many weak characters break that way. The trick is to make them choose their own deadline and fail.
I think I missed the title, main topic or perhaps even what you were replying to when you wrote this. Maybe there is a context. In its absence, this reads like a HowTo for getting someone you already don't like, to quit.
Clear communication is a very important managerial skill, by the way.
>The trick is to make them choose their own deadline and fail. That way you take away the scapegoat "they set unrealistic deadlines" because the engineer digged their own grave.
Manipulative, psychopathic behavior, and you are a bad manager.
> Nobody can work with engineers who are unwilling to commit to a schedule
Inability to state a time estimate is not the same as unwillingness to commit to a schedule. You sometimes do pioneering work which you really have no clue how long can take.
Estimating just writing code or doing something repetitive is easier than estimating research + prototyping/engineering.
If there is not enough information to make informed schedules, the only reasonable option is to DO MORE RESEARCH, not guess. Better still is to not try to create some master plan that requires things like this to be known at all.
The best way to evaluate the productivity of engineers would be to determine if their peers see them as a top performer, a net positive or a net negative. If somebody is a net negative, get rid of them. If somebody is a top performer, make sure they're compensated accordingly and kept happy so they don't leave. If somebody is a net positive then you should be satisfied that you aren't stuck with a net negative. Any attempt to evaluate software engineers beyond this is going to be inherently arbitrary.
If you invent arbitrary metrics, your engineers will often have to choose between doing work or gaming the metrics.
There's a guy on my team who everyone thinks is a bad programmer and general looks down on, but he is always willing to help, does a thorough job and writes generally decent code. I have no idea where his reputation came from, but it would be a shame if he were let go based on his peer evaluation.
If he does a good job and is always willing to help, that sounds like a net positive to me. It just might be that there are a lot of toxic team members
I get paid to give advice to tech executives and directors. Something I often have to say to them is: hire talented managers. Talent dominates technique. They need to stop reading blog posts like this and just think about talent.
We’re obsessed with technical talent but we hire managers at random after asking a couple of behavioral questions they’ve heard a thousand times.
This is definitely not universal. I'm at my 3rd organization in an engineering management capacity, and only the 1st one where I grew into the role didn't both put me through the technical gauntlet and explicitly interview for people leadership skills and experience. I think the challenge is that management is a more subtle skill with longer lead times to positive outcomes. There is no testable analogy for the coding challenge or take home project.
>> Talent dominates technique.
I really don't like this as it implies some sort of naturally leader vs. skill development over time. We'd do much better to optimize for affinity, desire and coachability in potential leaders.
What's your opinion of the new hiring standard that has arisen the last several years across Big Tech and has trickled down:
We're looking for an experienced Software or SRE or DevOps or X Manager in this exciting and fast growing company! Must be able to code in a job interview, have five years experience or more directly managing a staff count of at least ten engineers, and answer algorithm questions! We also expect you to know not just application architecture and CI/CD workflow inside and out, but experience with X and Y vendor applications, Z framework, and running Agile teams!
My qualm is that a manager can't remain a hands-on coder very long if they're spending their days in 1:1's, product meetings, negotiating with other teams to protect their engineers, and generally being good managers.
I'm baffled by how someone can be an experienced and talented manager, and also have their technical chops stay strong - forever. Technology changes such that what you became and expert at when you weren't a manager, is different from when you're manager today. All that remains are patterns, intuition and wisdom that can't easily be captured.
When you've experienced first-hand managing various personality types like 'shy engineer who needs to be encouraged' and 'arrogant talented engineer who everyone relies on but does what they feel like' and 'new junior engineer' and 'repurposed engineer who was doing a completely different role' as well as 'the other remote team that's just joined'... you realize these things are hard.
There's no way a heads-down coder can be good at these things. Unless they're elite geniuses or people who work 6-7 days a week.
So I don't understand the job specs for tech management today.
I’m not a manager but I’ve observed managers stay technically strong by being involved in technical activities. Participate in design reviews, project planning, on-call issues etc. being able to smell good vs bad system design does not change that fast. Also they’ll occasionally bust out a ticket that only takes a few hours, aka still able to commit code. I don’t think this is unreasonable for edge level managers. I even get good insight from managers at the director/vp level at where I work.
This is way too simplistic. In reality, everyone has a role, and if you don't understand that role then problems occur.
The fact is, in every organization there's the technical side and there's the political side. The bigger the organization the more need there is for a political, not a technical, manager. The former manages the people, stakeholders, etc. The latter manages the product itself.
In many organizations both roles are done by the same person, who tends to do one side better than the other. In engineering organizations the manager is probably more on the technical side because engineers.
The problem is that large organizations (insert your definition of large, it could be >20) or organizations with multiple customers managing upstream expectations and prioritization are really important. These people are paying the bills, after all. At that point you need to start fending off salespeople, account managers, and other executives.
Unfortunately, telling customers to fuck off you're busy isn't the greatest path to customer satisfaction, retention, etc. You need a political manager to do that for you.
I know of a few large orgs that have formalized this tech/political manager structure, because it's effective. But you need to understand what's happening and why. If something rolls downhill to engineering it's because the political side believed it was required; you need to accept that. Likewise if the political manager gets pushback they need to understand that the issue is real.
So taking a step back, the article is complaining that you should have managers that understand what engineers do. I'd flip that - we need engineers that understand what managers do. Engineers are not special. Neither are managers. It takes people working together to get stuff to happen, period.
> Stop estimating. I have analysed every team I have been on that use estimation. Those teams have been 99% incorrect. In my experience, it does not work. If you need dates, I would recommend a more modern approach like forecasting.
What does this even mean? I've never heard of a forecast that didn't use a combination of past data and an assessment of complexity of future work to assemble the forecast.
And assessment of complexity is the heart of estimation.
Can anyone help me because my imagination is failing me here.
The problem is that article is confusing the management failure of assuming estimates should be accurate and then punishing/rewarding based on accuracy of estimates with the proper practice of using estimates for scoping projects so they can properly prioritized and loosely road-mapped.
It's a throw the baby out with the bathwater problem.
Once again: no team or model or formula can produce a forecast without an assessment of complexity for the work effort being forecast.
So if what you're saying is true, this would involve someone other than the devs assessing complexity, then coming up with a date, and then holding the devs accountable.
And that sounds like a complete nightmare that's far worse.
The point of ML is that that can happen without human intervention.
And yes, I agree that if devs are held accountable to such timelines that would be terrible.
But if they are used for business planning with the understanding that they will not be accurate in the specific, but hopefully in the aggregate, then that's fine. (This is how engineer's estimates should be used as well for that matter.)
These are the endemic issues I have experienced after working for several SaaS vendors:
1) Rampant tech debt. Engineers are not empowered to fix it or their focus is on something else.
2) High barrier of entry. Most SaaS companies are bad at onboarding engineers or they simply don't care, usually because C-level staff and investors work towards sales metrics.
3) Mismanagement. Passive engineering managers who spend most of their time attending obscure meetings and expect individual contributors to chase them, maverick employees who do more harm than good, antisocial behaviour due to having no conduct expectations, etc.
My personal opinion is that nowadays SaaS engineering is akin to being a miner during some mineral rush. You can make significantly more money than the average Joe in exchange for a shorter life expectancy.
* Put them oncall on Xmas when they are new to the team (because teams are like army where the newcomers must suffer)
* be pedantic and hysteric in code reviews
* have meaningless processes that drag for hours. E.g. iteration planning that goes on for 2 days
* enforce nebulous "principles" (e.g. anything by RC Martin) because manager that hasn't touched code in a decade went to a show of him and was "impressed"
* have clueless architects design systems and processes. Specially anything microservices-related.
* have lesser engineers run the teams and processes. The kind that is good in Public Relations but have little or no real skills
* have id-politics matter more than anything else. E.g. most important problem this week being why women employees got a pink promotional cup and how is that discrimination
* do not allow access to web mail and a gazillion other sites because "security"
* do not allow local code (if you see this - run) and instead promote "dev" in remote controlled envs
* foster a blame culture (who did that?)
* foster a toxic culture where politics run the place
* fire good engineers and keep the above mentioned Public Relations ones
* have and promote managers that are good in gaslighting and not much more
* work for managers and with colleagues that you'd advise your kid to stay away from because they cannot be trusted
* hire titles with no real experience and many ego issues and push them hard through the ladder. Classic example PhDs straight from uni.
I don’t see “failing to fire bad engineers” on this list, which is a huge problem but easily fixable. A good engineer can put up with a lot of BS, but working with B and C level talent is a fast path to burnout.
I work for a company that doesn't fire no matter what. You can join and do nothing for 40 hours a week while never delivering on a single ticket in the issue tracker. True story there is someone here who has never had a single PR in nearly two years. He isn't a manager he's a dev. The other engineers can see this and it is immensely demoralizing and betrays such a serious dysfunction that no one takes this company seriously. To spice this up a bit this is a high end tech company which everyone reading this has probably heard of. The employee in question is not the only employee who does nothing. I would estimate roughly 10% of the company does absolutely nothing all day and another 20% work 20 hours or less a week.
I get why these "Managers are so clueless!" posts feel good and are often well received. One thing that would help is if technical talent didn't naturally position leadership as comprised of people who are totally different from them, who intentionally strive to create an unpleasant counter-productive environment that makes it hard to create and deliver software.
I get the pain expressed here, it's real, and the problems are REALLY HARD to solve. Any one of these is multifaceted and cannot be solved by "management" alone. Asking VPs to code a feature every quarter is both unrealistic and silly. Complaining about too many managers, meetings and processes is common and fair, but not to say "if you have painful process fix it with this different, equally strict and brittle process" is naive to the point of funny. Saying "estimation is hard so don't do it" an incomplete answer, and railing against smaller teams or realigning people broadcasts "I don't really think about budgets, emerging needs or things above writing code".
So much of this can be addressed within the team; you can promote streamlined process that does enough to align without prescribing, you can add some consistency in who does what work to build more durable teams and form a consistent mission, you can estimate in effort not time. The author seems to think the ideal is achieving stasis and maintaining it; to me this is impossible and actually sounds like hell.
The day that engineers accept the reality of reporting to investors who only care about cashflow and time is the day all those MBAs and managers go away. Until then, someone always needs to impedance match between the world of ROIC and the world of hackers.
Well said. Managing engineers is an incredibly difficult and multi-variable challenge - companies have been trying different approaches for nearly a century now. We like to imagine as software developers our management problems are unique and can be solved with a silver bullet blog post, but I think they’re largely the same meta-issues that Ford faced in the 30s or Boeing in the 90s.
Hiring cheap contractors can be frustrating too. I am on a project that is behind schedule. Management’s solution is to temporarily staff the project with several temporary, cheap offshore developers. I think a smaller team with competent folks can be much more product. There’s a lot of truth to the book, “The Mythical Man Month”. Now, we have far more meetings and communication chains. We also have to spend multiple cycles reviewing the contractor code and helping them learn software development.
If it's as bad as you say it is, collect evidence and prove Mythical Man-Month to them. Explain it's wasting more time AND money, and the deadline is missed regardless. Hopefully they'll listen.
It might be, but in my experience the hardest conversations are the best ones to have. If it all goes to hell, time to vote with your feet and dust off the resume, then.
So, many of these I agree with, but not this one: "Hire managers that cannot build software". Managers that cannot build software are, in my experience, just as likely to be good (or bad) managers as managers that were good programmers. Managers who used to be programmers are sometimes clueless, and aggressively so, about people skills. While it is possible to manage programmers well without programming skills, if you work at it, I don't believe it is possible to manage programmers (or anybody else) well without people skills.
Software managers who were never programmers _know_ they don't know about programming, and understand that this gives them some blind spots, so they are often willing to take constructive, professional, tactfully given hints on that. Software managers that were programmers, in some cases, not only don't have people skills, they don't think people skills are important or useful, and they don't try to get better.
Not saying former programmers _cannot_ be good managers, I've seen some that are. But I don't think non-programmers are, on balance, less likely to be good at managing software development, because they know what they don't know, and managers who were formerly programmers often don't.
Specifically about managers that don’t have technical abilities - installing “agile coaches” as the scrum master and other Big Agile TM nonsense. Maximum micromanagement and a team getting ever more exhausted and demoralised.
The previous big bank I worked at did this all, they had an agile coach and multiple scrum masters. The agile coach would essentially sell agile to management, and then blame development teams for not delivering what he sold. Building a product almost became irrelevant.
We seriously had a full day of sprint planning. Even had meetings where we had to deliver a feature in two weeks, and the agile coach put us all into a room to figure out how we could use agile to deliver this. He also constantly pushed his technical implementations, despite being a non-technical person.
I believe of the 12 devs across two different teams, only one of them remains at the company today.
My first instinct was try and fight it, try to explain why this wouldn’t work. But you quickly realise the agile coach wasn’t there to help development teams, he was there to sell agile, so he could remain employed.
I totally agree with this. I am in a situation right now where the skip level manager is asking to schedule meetings every other day to talk on a problem that requires research. They want to talk about a solution and not letting us find one. Another one is defining aggressive timelines when I don't even know what to solve. Obviously the timelines were shot to hell in the worst way possible.
In the same boat. It's painful, whenever a bug appears or there's something they don't understand; boom! A meeting gets scheduled. It kills the soul nevermind productivity.
The other one is having to answer the same questions over and over.
When you're about to go to production, tests have been written and everyone's done their part, you'll get asked, "so you're sure nothing will break production?" It blows my mind.
In the nicest way possible, get those meetings canceled. Show initiative by simply saying "I will provide an update by the end of the week; let me do my research first."
If the skip-level is refusing to stay out of your lane and not let you do your job, it might be time to dust off the resume. Thankfully, the market is crazy hot for anyone not a junior. Still, that sounds bloody awful; I am sorry you are going through that. :/
And in the best way I can say this, but deadlines don't matter if they are not set by your engineers AND accounting for the time to add unit tests/integration tests/bug fixing/clean code. I've inherited plenty of salvage projects with terrible codebases that eventually get scrapped wholesale and redone from scratch - so if someone tells me to cut corners for bullshit deadlines, I'll push back with those stories and keep the course. Call me cushy/inflexible/unrealistic, but I refuse to write a salvage project of my own.
It's a mentality and culture difference. Manager-type people solve issues by having meetings, lots of meetings. Their work is accomplished in the meetings. The can have 7 meetings on the same day, each about a completely different subject and still manage to get something done.
Programming on the other hand requires uninterrupted blocks of time. Working on 7 projects on the same day just means you have 7 projects that didn't progress. Having to sit in a meeting every other hour means you're not getting anything done between meetings because context switching takes time.
Reading this article and the comments here is like group therapy. This feels like a nearly-universal experience; the shared trauma of pouring everything into a project only to see success destroyed by incompetent management.
I've been writing code for a living for 20 years and I swear it wasn't always this bad. There were fulfilling software jobs at one point. What changed?
This! It's more or less impossible to correctly estimate how long it will take to develop anything but the most basic pieces of software, and even then you can't be sure.
I've had so managers who just don't get that there are so many unknown variables in the software development process.
No matter what estimate you give, you cannot win. Estimate short, but it takes longer? Then you are accused of not knowing what you're doing. Estimate long, but come in short? Then you are expected to shorten all future estimates. Estimate right? Nah, that never happens.
Every price of software developed is different and will take a different amount of time to be developed. It is really quite stressful for a dev who is working their ass off to hit difficult targets in an organisation that refuses to be flexible about that sort of stuff.
Give three estimates. One if everything goes well, the most optimistically you can imagine. One representing the most likely path. And one representing the worst-case scenario. Let your manager digest from there.
If you have a bad manager (e.g. they would just use the best-case scenario estimate and ignore the others), average the estimates, 1 part best case, 1 part worst case and 4 parts normal case. Then try to make sure you are giving a set of estimates, not just one, and usually it will average out.
Step two of having a bad manager is finding a different situation, whether via internal transfer or a new job.
For me I had one manager where every time he said "how long will is take?", I got that feeling of fear and dread in my stomach. I suppose the problem was that he wasn't asking for an estimate, he was asking for a specific date when the project was fully deployed. He wanted pinpoint accuracy, even though that was impossible. Missing or undershooting a target would have him bringing you into a room where he would start interrogating you about what he perceived as a personal and professional failing on your part.
So anyways myself and others started pushing back and refusing to give estimates and instead just saying "it will be ready when its ready" and when pushed giving super vague time frames like "a few months". He did not like that.
I see posts like this and wonder if software developers are in such high demand that they're able to call the shots these days but many of these points are come off as very arrogant.
> Make your engineering managers, Directors or VP’s take about one week in a quarter and get them to build and deliver a feature.
While we're at it, why don't we also get them to design a part of a car, design an icon for UX, do some accounting and have them do a legal brief?
> Stop estimating.
How does this person think an organization schedule, budget and allocate resources?
> In my opinion, Have a minimum team size of six.
To build what? Some production software can be built by one person. Some need hundreds. This is like saying an organization needs a minimum of $1.5m annual budget for software development because it's software development.
> How does this person think an organization schedule, budget and allocate resources?
Collect data and use a trivial prediction model (i.e. median calendar time it took to complete the last 5 stories). Monitor and improve the prediction model over time if necessary. If you’re not collecting data reliably enough to generate a prediction automatically, you’re not taking any of these issues seriously anyway.
That's just a way of estimating that is likely quite accurate in a completely steady state.
But what if you know you're changing things significantly, and that's the whole point you need to think about resources and schedules? Like starting a new project?
Use data on how long it takes to complete “projects.” Or break the project down into your best projection of the component tasks and multiply “number of equivalently sized tasks” by “average time to complete that sort of task over the past X months.”
Regardless, “collect and use data from the past,” does not require a “completely steady state,” and is pretty easy to modify. I’d feel a lot better having a conversation around, “this is totally new, do we think it will take about 2x or 5x longer than our normal projects?” Vs “this is totally new, so everyone guess how many months it will take without looking at any relevant data on either past project duration OR the accuracy of your past guesses.”
When people talk about “estimating task size” they almost invariably mean some planning-poker version of the second. Especially in TFA where they bring up forecasting as a better alternative.
I suspect that the author has never actually worked in a flat organizations, it's been my experience that flat organizations have way, way more problems than "too many managers."
Once I worked for a company which I prefer not to name here. They wanted to solve a huge problem which I have solved during my previous tenure elsewhere. Once I learned that they are trying to do this I offered my help.
I realized that they picked someone with zero experience with this who was about to make the same mistake(s) I made before. I managed to talk with the VP about this problem and after about half an hour I realized that the person who was responsible for this decision not only didn't know anything about software development, but he also didn't know what the problem was and why we wanted to solve it.
A day after this talk I've heard that a very high level IC resigned so I had a talk with him. As it turns out he also worked on this problem before and spent 3 months trying to make his point about this and after he utterly failed he just couldn't take it anymore. I also resigned a few months later.
Having managers that have no idea about how programs are written and how the whole process works is a surefire way to sink the ship.
Needless to say this organization had layers after layers of managers who all tried to protect their turf from all the potential damage others can make.
The definition of engineering manager who doesn't know how to do stuff and it's solution is very wishy-washy. Based on experience, this works in some contexts but not all. I think the author's hearth is in the right place, but the way it's explained is very short sighted. In other words this makes me think the author has never worked with an eng manager.
Layering: good problem to solve, solution? In theory, but in reality this is also very difficult to balance (e.g. from experience, especially when moving above 150-200 ppl working in the same area).
Too many meetings: very good problem. Solution? Partially meaningful. If you want to generalise, my take would be to make things async as much as possible. Collaboration between teams might be needed, and perhaps healthy. When you don't have collaboration you end up not knowing what's going on (i.e. isolating teams) and risking pulling meetings over and over.
Software definition; mostly agree, but again, the solution is much more complex than what the author leads to believe. Also assumes you have testers and product will be happy to sit through each ticket revision. This problem is solved by anticipating these requirements way way earlier than that.
Software delivery: are we talking about technical debt or what? If that's the case, the solutions (20%) make no sense. That's where you start diving into each single problem, breaking them down by priority, involving product and making sure things are tackled at the right time.
1: to cut a hole through the bottom, deck, or side of (a ship)
specifically : to sink or attempt to sink by making holes through the bottom
The actions of these people make you to give up on Occam's razor in disbelief. Sometimes they're the owner of the company who are doing everything someone who'd want to sink a ship would do.
The worst is when the ship was amazing (generating revenue like crazy, great reputation, top notch record, satisfied clients).
Also, promise people equity then change the goal post by introducing new variables, haggling over everything, and attempting to screw them in every sentence (for instance, change the vesting period in one sentence, add a condition in the next sentence, claim they've had no impact on the company in the next, threaten to fire everyone in the next, add yet another condition in the next, tell people you can't give them the equity you promised because you promised someone else and do that for the other person too).
That's, in essence, how to fuck up your own company lightning fast.
* When a project is declared "finished" break the team apart and spread
them about the company. Because the original dev never see the code again,
why should they care.
* When a project is late, and it always is, pull out the original
schedule rammed down our throats when the project was first started.
Then it's easy to see who to blame.
* Have legal (YES!) decide rules for agile. True: they decided on 1 week
deliverables, demanded complete documentation per week, insisted on a
waterfall approach to design and dev. "When you've done it, you don't
have to revisit the past!"
* Documentation was in charge of dev: "They read the docs and know what
needs to be done:. I never figured out who "they" were.
* Create a lengthy, complex paper trail for deliverables.
True story of one company - now extinct. They had about a 50% turnover rate.
Just reading the beginning of the article, and I couldn't help re-re-emphasizing how critical it is - as a manager at any level - to conduct "exit interviews" with your report-tos and other dependents, right when taking over a group. This was one of the best methods I leveraged, in my over 25 yrs career, in all sorts of low or senior management positions, i.e. serious "exit interview" with any team I got anew, which helped me gage some of the insides. Simple questions like "why would you leave today, should X, Y and Z be no different somewhere else" and "why would you stay, should X, Y and Z be better somewhere else", etc., of course with very well refined variations on the X, Y and Z and topics derived from the initial questions, depending on the environment. And I always warned the folks about the "exit interview", and given some hints on what questions I may be asking, to let them prepare for the actual conversations to be had on this topic.
I think some nuance is being missed here. I’ve had a manager come in and ask questions like this and immediately turn around and use the feedback to fire people and rearrange the department.
That sounds like a good thing or was it too fast? Most companies do nothing to address the problems following exit interviews and them end up with terrible retention
People were fired for systemic issues they criticized. Non of the issues were corrected and the new person started handing down questionably legal changes to our platform.
As someone who has been in industry for over 20 years, I have been spending a lot of time thinking about and living thru this. For me, my manager and my relationship with him/her is probably the most important aspect of a job. A few things that I have learned:
* Manager maturity. Young managers tend to be very hands on, they will naturally micro manage. More times than not they were previously an engineer, possibly in the role your currently in, so they continue that role, but with manager power and authority. Young managers work best with younger employees. Young engineers need hands on managers to explain things and mentor them, and that plays well into a young managers need to manage things.
Older, experienced, and more mature managers tend to learn what their value is and where they are important. Usually that means listening, coaching, and communicating. Technology has literally changed under their feet, so they tend to be hands off. They also rely on their team more to make decisions and drive towards success. They depend on you. These managers tend to work well with senior engineers (a senior engineer is someone with decade(s) of experience).
* Conflict. A few years ago I did a handful of manager interviews with some top tier tech companies. I was a bit dismayed that these companies were not looking for nice guy managers who values things like compassion and supporting their employees, and possibly even be friends with them. Rather, they want managers who are hard, can wield power, and comfortable with conflict. Conflict here means that management and employees are in constant dispute over literally everything. This means that managers are constantly squeezing work out of you and will have no problem introducing politics and other authority techniques into their day to day managing.
* Communication. Open communication is extremely important. What I find is that when you have many layers of management, decisions are made using information which needs to be withheld from lower levels (or decisions are made based on no information!). When it reaches the lower level, it seemingly makes no sense and can be confusing. Good management communicates everything and does so transparently. This way everyone understands the what and the why. If you don't agree, given you know the why, then you are at least better prepared to pitch an alternative or make the needed changes. If the why is something contentious like you or the team is underperforming, then again, its best that is communicated so everyone has the power to make corrective action, if they choose.
I think a lot of this comes down to culture. A good culture values engineers and adapts to making them happy, as that is how you get the most productive engineers.
Charitable read: OP probably didn't mean "minimize collaboration" but "minimize the need for collaboration."
Or phrased differently: design your teams so that the most common tasks can be done by a single team.
If support needs to talk to the developers for every single support request, there isn't much need for a separate support team. If, on the other hand, the support team gets all the tools and training to address the 99% most common support cases, support gets faster and developers get fewer interruptions.
- Lowering your hiring bar. When you hire people the burden to get them up to speed and productive is on the existing team. If these people are smart and motivated, great! But no-one benefits from having 200k+ engineers now have to spent their days explaining how GIT (yes, really...) works to a small army of juniors.
- Not involving your current team in decisions that affect them. Re-shuffle the teams around, re-architect the product, change the existing workflow, etc. If you hire professionals with 10-20+ years of experience just to ignore their advice, they're going to be looking for an employer that does appreciate their input very quickly. Nothing is more frustrating than telling a manager not to put his hand in a pan of boiling water, just to see him do it and then blame the cooks for having a pot of boiling water around :)
My current manager decided to add 50 outsourced engineers to a team of 5 to deliver the product in a year (instead of the 1.5 - 2 originally guesstimated).
In addition to this he decided to give the responsibility for the architecture of the application to outsourced "solution architects" with no domain knowledge and reorganized the teams to split them by job title (e.g testers, developers, operations, "management", etc).
Current productivity is lower with 55 than it was with 5, 3 out of 5 have already handed in their resignation. We're burning through an additional 3 million this year with 2 crappy React pages to show for it.
Next year the damage will probably be worse given the rapid outflow of talent.