61–70 of 316 posts
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 decis…
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.
Earlier quoted context omitted.
I don't agree. Its perfectly reasonable not to have any idea about an estimate until after an investigation or prototype has been produced. Demanding an estimate up front for something totally new just makes you look inexperianced or bad at managing engineers.
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 char…
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.
"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…
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.
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 understan…
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 :)
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…
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.
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 a…
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.
Earlier quoted context omitted.
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.
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 bo…
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.
"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…
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…