24 ms·

Developers can't fix bad management (2020)

380 points by sidcool 5y ago

sadmann1 5y ago
No but they can bear the blame until they burn out and afterwards be replaced by a fresh bundle of youngsters. That's how it usually goes at the companies I consult to clean the mess
villasv 5y ago
Every organizational problem is a management problem. I doesn't mean developers can't and shouldn't try to fix it. Concluding such article with "Developers are fine" is too cynic. For reference, at my org, management already does what it says it should do and already don't what is says what it shouldn't do. Still there are developers who need to step up their business understanding. Despite all the training, the stimulus, the right incentives, it is not natural for new tech/team leads to communicate well how technical challenges must translate into business decisions. This shit is hard and complex, stop trying to assign blame.
- pdimitar 5y ago
  I treat all such articles with the condition of "I am not saying this happens everywhere but it happens fairly often" -- which is also my experience. I've met several excellent managers and I have huge respect for them but seriously, they are rare. I am almost 20 years in the industry and I am not sure I've even met 5 of them.
  - villasv 5y ago
    My point is not that good management is possible. The article drew conclusions to which my experience is a counterexample.
gregdoesit 5y ago
I have a theory on why we're seeing so much "bad management" for software engineers: most leaders at workplaces have not been engineers themselves at a company with a great engineering culture (I wrote about what I think this means [1]: it's all the high-growth small and large tech companies we know) The CEO, and the people under the CEO know and understand traditional, top-down management. Let the people with context and decision power make the big decisions, and pass this downwards. Works with finance, works with marketing, works with IT support, and should work with engineering as well... right? But it actually doesn't work with software engineers as well as it could. Or with designers. UX researchers. PMs... all these people would produce a magnitude more output when given proper context and autonomy. A few leaders read about this, and try giving autonomy. These results end up even worse than the status quo, as you can't just make it a free-for-all and expect it works overnight. And to prove this point: look at companies where the founder had worked at a high-performing company before. Before founding Twilio, Jeff Lawson spent years at Amazon (he was one of the first AWS PMs), and in his book Ask Your Developer, he writes about just how much this experience shaped him, and all the practices he adopted from Amazon. There's this really weird divide between "forward-looking tech companies"[2] who "get it", and everyone else. Which heavily benefits this first group. [1] https://blog.pragmaticengineer.com/the-developer-culture-test/ https://blog.pragmaticengineer.com/the-developer-culture-tes... [2] https://news.ycombinator.com/item?id=25717390 https://news.ycombinator.com/item?id=25717390
- jbverschoor 5y ago
  It's not "traditional". It's common sense. You can't let an X company be run by someone without any affinity of X. Would you let a painter do surgery on you?
  - Jenk 5y ago
    > Would you let a painter do surgery on you? False comparison. It should read "Would you let a painter _manage the surgeons_ who will operate on you?" Having worked in the healthcare industry - the answer to that might surprise you.
    - pdimitar 5y ago
      To be fair, I am pretty sure most people here in HN wouldn't be at all surprised. We're very used to watching laymen having to manage potential millions of revenue.
    - jbverschoor 5y ago
      I guess it's the right example, because healthcare is a mess as well
- Jenk 5y ago
  Crappy management begets crappy managers. Agreed. I have a counter/supplementary theory that it is just as disruptive to assume a good developer will be a good leader or manager, too. Rant time (aimed at no one in particular, especially not parent comment): Managing is a very different skillset. There needs to be some significant knowledge of the industry at large, the specific domain that is relevant to your biz, and "generic" (for lack of a better phrase) management skills (i.e., communication and management of the squishy bits of your org that show signs of sentience and sometimes speak) I've lost count the number of times I've heard colleagues say "They are such a bad (technical) manager, they'd never be able to do what I/we do." and have responded with "They don't need to. That's why they pay you." I get very tired of this "debate" that it is management _versus_ IC/developer/engineer/worker. I also strongly believe a lot of what is perceived as "top-down" management is harbored by a "bottom-up" resentment - or just plain resisting authority. You are a team, so work together. I also hold the opinion that if your organisation has this mindset ("versus") within then you have a much bigger problem than what is presented at face value.
qrbLPHiKpiux 5y ago
So, developers want a blank check, is what I’m reading?
codebolt 5y ago
As a developer, I got some valuable insights from the book Extreme Ownership by Jocko Willinck. I think particularly the principles of "leading up the chain" is crucial when you're a developer with managers who don't have the necessary context of understanding to make optimal decisions on their own. Perhaps not as easily applied in all company cultures. But in my case, it gave me the confidence to voice my opinion on a few critical issues of strategic importance over the past few years. This year I was promoted to "system responsible" (basically lead dev with technical responsibility for the system) and I think that was in part an acknowledgment of my ability to take ownership of a situation and helping to make sure sound a sound strategy is in place.
- plasma 5y ago
  I can also recommend this book (it’s on Audible too and a great listen).
- proc0 5y ago
  Check.
Ozzie_osman 5y ago
> In most companies, management is actually to blame for deliberately isolating engineers from discovering the customer's needs. News flash! Developers actually like the idea of figuring out and fulfilling needs with epic software solutions and are fairly neutral-to-downright-annoyed at spending their time creating something that no customer wants. I agree with the first statement but disagree with the second. Yes, management is often at fault for not involving or engaging developers. That said, I've seen many really solid developers be motivated by solving complex technical challenges instead of work that actually creates business/product value. Of course, it's management's responsibility to harness that energy and align it with creating value... But just saying, a lot of really smart people are driven more by intellectual challenges than product impact.
- jdowner 5y ago
  I can say that this is true for me. I like helping people but I get my motivation from feeling that I have solved a problem well. Maybe it is the nature of the kind of software I tend to write, but I'm not all that interested in whether it is used by millions of people or purportedly helps a bunch of people. That's nice, it's just too far removed from the work for me to be motivated by it. The bonus is that I also don't have an issue if something I've worked on is scrapped for whatever reason, and I know that that is something that some people have a hard time coping with.
- Aeolun 5y ago
  Technical challenges that are actuslly used beat out technical challenges that are just for fun though.
  - UncleMeat 5y ago
    That depends on the engineer. There are absolutely people who aren't motivated by impact whatsoever.
    - lanstin 5y ago
      And their coworkers will be able to find nice complex isolated problems for them to solve. That isn’t a problem in for the group in general, because that is like finding a really nice tool that you can use however you like. And most any domain can use brilliant solutions, if you think about it for a few days.
kbmunchkin 5y ago
After 12 years of software development, I've come to the conclusion that software managers are not needed. From what I can tell, they have meetings, try to get people to work more, and approve time off. The best team I've been on didn't have a manager. The lead developer handled communication with the IT Director about project status; and that wasn't very often. We had no meetings, or KPI goals, and other such nonsense. That is, until the company was bought. Everything changed after that and traditional management took over. Most people left within a year.
- Aeolun 5y ago
  The best teams I’ve been in have been the ones where there was no filter between the developer and the client. The more filters, the harder everything becomes.
  - swader999 5y ago
    Co-located with your users for the win. If there's such a thing as a silver bullet in this space this is it.
    - Mauricebranagh 5y ago
      Yeh Back in 94 I and another developer got flown up to Edinburg and delivered using RAD/DSDM in a month what a another traditional team said would take 2 years. One of the other ideas at the times was a custom BT version of HTML - that got stamped on very had by the Labs thank god.
  - alistairSH 5y ago
    Perhaps, but that doesn't scale well. My previous role, I served 100s of clients, each with 1000s of end-users. If those users had direct access to my development team (5 devs, 2 test engineers, 1 BA) they'd spend the entire day fielding requests and get nothing done. So, to avoid that, you add a product management team. And an SDM, who acts an umbrella over the dev team to prevent shit raining down on them from tech support, product management, sales, etc. I suppose that's the key - if an SDM doesn't see themselves as a shit umbrella, they aren't doing their job. That's not their only role, but from the developers' perspective, it's perhaps the most important. Edit - the team did interact with customers via various channels, but it was more controlled than "unfiltered". We had a forum where both sides could communicate (though the BA typically did the lion's share of that work from our end). We also had periodic beta review meetings with select customers. And of course, when tech support issues got to our level, we were often on the phone, VPNed into their systems, etc. But, between the BA and I, we triaged most inbound communication, and there was zero expectation a developer would respond unless specifically asked by me or BA (though they were free to do so if they wanted - most preferred not to do so).
sidlls 5y ago
It's not as straightforward as the author of this article suggests. Not all engineers do care about whether their work serves the company's interests, and some (many?) will go out of their way to square a round hole, so to say, to justify some itch they wanted to scratch. I know the HN take on things is that the best engineering management comes from people who are/were engineers in the past. But, respectfully, I just have to disagree that they're any better, especially if they come from "big tech" (e.g. FAANG). There's a real (terrible) tolerance for vanity projects, gamesmanship, and ego stroking that comes from that lot, IME.
jph 5y ago
Developers have opportunities to improve management by increasing management-visible headlines about user goals, and decreasing management-visible headlines about implementation details such as UI, WBS, wireframes, flowcharts, and tech. Try this thought experiment: Imagine you have team task list with headlines such as "Add red button to top of home page". Imagine rewriting the headlines such as "Customer wants to contact us" and similar kinds of user stories. When managers continually see headlines with user emphasis, and do not see headlines with implementation details, then management improves and developer autonomy improves, because both groups are looking toward users. It turns out focus on user stories can help significantly, even more than some developers might intuit. Look at your task board headlines and the opening paragraphs of your management-visible writing-- can you improve your writing to emphasize user goals?
- ClumsyPilot 5y ago
  This is such a good point, Its a bit like how developers neglect to write documentation, developers often neglenct to communicate effectively or create 'communication artefacts' like diagrams, etc that make their work more comprehensible
  - jgeada 5y ago
    Interesting that developers are expected to do all this other ancillary work that is the remit of other professions. How often do we expect the technical writers, marketing, sales, management, etc to also do their share of writing the code? I too would like to do lots less work and have other professions help out and be available for the scapegoat game when it goes wrong. Documentation not up to par, blame developers. Marketing failed to achieve goals, ...
    - ClumsyPilot 5y ago
      I think the person doing much of the communication has to be the developer, noone knows what's happening in hid system better than he does. But that must be a separate activity pruoritised and with time allocated. Lawyers have to do many anciliary activities, but they are given time to update their qualifications, etc by their employer
whoomp12342 5y ago
Can I point out the fact that this article compares software developers to auto workers trying to explain the problem and then highlights failed management strategies as a fact that software development is nothing like manufacturing, saying " and if I ever run a factory, I'm gonna use it! But it has no place in software projects." I dont disagree with this article in general but please dont contradict yourself.
- commandlinefan 5y ago
  I don't think he really contradicted himself - what he's saying is that auto workers fell behind because management was trying to manage them like farm workers when they weren't, and that software is falling behind because managers are trying to manage them like factory workers when they aren't.
jillesvangurp 5y ago
People self select to be in these situations and they can self select themselves out of it too (by changing employer). There are lots of not so great engineers working in not so great companies. Good engineers tend to have options to improve their work situation and most of them do. Sometimes they are happy to take the money for an easy job as well. However, I see a lot of issues that have also to do with a few factors that are hard to control: 1) programmers are mostly young. There are older programmers and they don't actually disappear (I'm one of them). However, the number of programmers keeps on doubling every five years meaning that at the ripe age of 46, I've experienced about five doublings meaning there are about 16-32 x more juniors aged 20-25 active than people my age. I work with a lot of people half my age currently. 2) Most people aged 30 would count as "senior" because they are relatively scarce and more experienced than most programmers. I got that label slapped on me around that time. That's nearly 17 years ago. I did not have a lot of experience at the time and I've certainly learned a lot since then. This is a common pattern in our industry. We have a lot of very junior senior engineers rediscovering a lot of things about software engineering every generation because there are very few proper seniors around to learn from. I'm usually the oldest person in a project and that's been the case for almost ten years for me. Yet, I know lots of engineers my age as well and most of them are in a similar situation. 3) Scrum adds roles to teams that I would classify as junior management. Product owner or scrum master would be good examples of job descriptions that end up like that. I've experienced more than a few PMs that were effectively on their first job and scrum masters that had little more than a two day training + a hand shake as management background (been there, done that). Junior management and junior "senior" engineers adds up to very predictable issues. Sometimes it works. Mostly it doesn't. The problem is not the process but a lack of experience on both sides. Hiring more people makes it worse. 4) Proper seniors are expensive but being old doesn't necessarily mean you are very good. I know I have to work hard to keep up with younger people. There's something to say for removing mildly burned out cynical forty somethings from your team. I've had to make calls like that to resolve a few toxic situations. Putting an old person in charge does not necessarily solve your problem either. 5) Software engineers generally lack soft skills needed for management and there's a lot of pressure on people to get promoted to their level of incompetence. Once that happens they are easy to manipulate by senior management. Large organizations with a lot of middle management that isn't so great fall victim to this. It' a classic A's hire A's and B's hire C's. Replace hire with promote and you have basically a template for how great companies almost inevitably turn mediocre. The A's tend to leave when that happens. 6) If you think forty something male programmers are scarce, try finding a forty something female one. They are a small minority in any age group but the golden combination of being forty plus, female, and still doing actual engineering is super scarce. As in: I struggle to name a single person that qualifies as that. Most women I know that age have long stopped being engineers and have turned manager or changed career entirely. Women generally are better at soft skills and make great managers so it's not the worst thing. But there's also sexism that drives them away from engineering prematurely before they've had a chance to become really good at that. I know more than a few women that have hit a glass ceiling where people just naturally assume a lack of technical skills because of gender bias. If you have the option, balance your teams as much as you can and things will get better. Resist the urge to put the girls in charge because they are girls. That's a form of sexism that helps no-one. Instead promote them to being tech lead, senior engineer, principal engineer, etc. They'll make better managers when they are ready for that career move. Better still, they might attract some junior female talent. Women generally know where the good jobs are. I've been in a few places that had good policies on that front and it makes a difference.
forinti 5y ago
The best manager I ever had really just left the team to do its job. I think we might only really need management on a higher lever for large projects. We certainly don't need Project jockeys for managing very small teams. As with many things in software, we don't have the maturity to clearly identify where the complexity and overhead are needed. A project manager for a 3 person team is like a bloated multilayer web app that gets 50 users a day. It's just superfluous.
agentultra 5y ago
It's not for lack of trying. A large part of developer culture is spent on working against or around bad management. Agile, XP, scrum, etc. Piles of books on it. Youtube channels and blogs dedicated to advice on how to navigate bad management. Bad management is everywhere. We humans are not very good at managing knowledge work. Worse at software in my experience. And all too often I see software developers taking the blame or blaming themselves. A good deal of software errors are enabled by poor management practices. When you let off the management reigns and trust developers to understand the importance and impact of their decisions you get a lot better results.
- thrower123 5y ago
  The insidious part is that every effort to work around bad management of this type is captured by management, and twisted, corrupted, and festered until it becomes yet another torture inflicted by management. Agile would be just fine, if it was the bottom-up, developer-focused scheme that the manifesto writers and True Scotsmen claim it to be. Unfortunately, it's been co-opted, and we end up with interminable daily standups that are driven by line managers, or by yet another useless person who bought a Scrum Master certification, and exist solely for developers to justify themselves and kowtow in self-abasement. Likewise with the whole cavalcade of infantilizing sprint planning meetings and planning poker and retrospectives and meeting after meeting after meeting imposed as part of a holy Process, that the company spent tens of thousands of dollars having consultants implement.
  - vbtemp 5y ago
    Agile is exactly the corporate management hell it claims it was out to solve.
- ornornor 5y ago
  > Piles of books on it. Youtube channels and blogs dedicated to advice on how to navigate bad management. Can you recommend some? I’m at a point in my career and at an organization where this is a matter of survival way more than actual competence.
commandlinefan 5y ago
> Software development is much closer to creating a new factory than running an existing factory This has been known, and ignored, for at least 30 years now.
- jimbokun 5y ago
  Known among software people, non-software people often need to be informed of this.
  - commandlinefan 5y ago
    Maybe "ignored" wasn't the right word... rejected might be a better term.
travisgriggs 5y ago
Wow. So much of this article resonates with me. Strong parallels with the recent re-debate of "bullshit" jobs. I have the privilege of working in a pretty low management shop, but sometimes it rears its ugly head and I chafe at it. Of recent I've observed that not everyone is like me in this regard. Even though humans don't like being managed, they also don't like taking risks. And for some people, the ability to offload risk, accountability, and liability to a scapegoat figure that is inconvenient to deal with at times (e.g. a bullshit manager) is actually a purchase they're willing to make. It's ironic to me, that years ago, the world had lots of clerks (people who kept the wheels of process logistics rolling) and less managers. Today, there are fewer (almost no) clerks, but lots of managers. Look at what most of your manager does, and see if (s)he isn't mostly just a clerk that collectively figured "manager" pays better.
orsenthil 5y ago
All problems can be fixed. How you fix them is relative to what are you trying to optimize for. If the management is bad to development culture, the developers can go elsewhere. If the leaders (including developers and management) is bad with decision making, the market will fix it.
managementwoes 5y ago
When a project is delivered on time, within budget, and produces the expected value for a company, it is not necessarily the result of "good management". This is why "bad managers" survive in our industry, far too often a manager's performance is measured on the success of the projects they are "accountable" for. I believe the responsibility of a "manager" is to provide support to the people they "manage", which can take on many forms. e.g. - Hiring additional staff to handle the current workload at the desired cadence. - Influencing the stake holders so the business priorities benefit their employees (and indirectly the company). - Providing emotional or moral support to their staff. - Being a source of motivation through exuding passion, or setting an example that their staff aspire to.
- k__ 5y ago
  Reminds me of a small-ish company I worked for. All promotions were based on the fact that the original person holding the role left. You could end up as head of r&d with being just out of college for two years.
nickthemagicman 5y ago
I found business analysts and project managers to be wonderful. Managers are just useless layers of bureaucracy and their job could easily be automated. MBA programs are the easiest of all of the graduate degrees. But because of good old boy networks, MBA program networking, and mangers hiring other managers the parasite continues to spread.
- steveBK123 5y ago
  Agreed. PMs/BAs are going out of style in favor of "product managers" and it's a huge mistake. Most of my friends who are in technical lead roles would kill to have a dedicated PM to do the parts of their job they don't like and aren't great at. Given the pay differential, it would be a good trade for most employers to do this as well...
  - nickthemagicman 5y ago
    I've only had the luxury of working for one company that had BAs. But it was absolutely wonderful. They would communicate with the stakeholders and users and other groups to flesh out the specification. And they would bring the specification to the developers almost fully formed with what we had to do. So from there we just were able to just engineer! Which is really what our specialty is. It was heavenly to me, because I find the most painful part of this career is trying to squeeze, schmooze, and cajole a coherent specifications out of stakeholders and users. I firmly believe a good project manager can be the difference between a projects success and failure.
ineedasername 5y ago
Just another story that essentially says everything would be great if only the developers ran everything. It's an over simplified view of how large organizations function. It is also a story the pretty much every group in an organization tells themselves at some point: from HR's perspective things would be great if the company just let them if the company let them pursue their vision of proper talent acquisition. The sales team believes they're most important because without them there's no revenue and they understand customers the best because that's one if their closest contacts. And so on. The truth is that no one group would accomplish much if they were the only ones in charge. In reality, there should be a seat at the table for all of the groups. Absolutely developers should be in the mix for understanding customer needs and helping guide things appropriately. But developers are no more inherently capable of understanding those needs than anyone else, and in fact a non technical view is just as important when the target audience is not just technical folks. An organization will fail when pretty much any one of its groups is sufficiently bad at their job, and will rarely succeed just because one group is good at theirs. But the "if only developers ran things" trope is old and worn and wrong.
- nine_zeros 5y ago
  > Just another story that essentially says everything would be great if only the developers ran everything. It's an over simplified view of how large organizations function. Just another manager who wears their ego on their sleeves. A lot of developers handle EVERYTHING (including politics) in modern companies except promotions and performance reviews. There is no real need for a manager if devs are doing everything.
  - kenjackson 5y ago
    > A lot of developers handle EVERYTHING (including politics) in modern companies except promotions and performance reviews. There is no real need for a manager if devs are doing everything. Which modern company does this? The closest that jumps to mind is Valve.
  - ineedasername 5y ago
    Wrong: I'm not a manager. Check my profile, you'll see the area I work in. I have no interest in being a manager because I understand the different skill sets and what I enjoy doing. But if we're bringing the issue of ego into it, there's yours right on display thinking developers know everything. Well, consider this: If you were right, there'd be a lot fewer startups with great ideas that flop even with developers in charge, but they fail because they can't execute on their idea by also running an organization properly. Developing code and running an organization are different skill sets, and not many people have both.
taeric 5y ago
Managers shouldn't be there to manage the people directly. They are there to manage the processes and environment. If a process isn't working, step in and prod it. Remove if necessary. Add where necessary. Sometimes repeatedly. That is, add then remove them add the same process. To that end. Developers are there to manage the code. Apply the same rules. Don't be afraid to try last year's failed strategy. Or to take out last year's success.
codeviking 5y ago
A lot of the ideas communicated resonate with me. The estimation process doesn't work well, and creates friction when things change that can interfere with the delivery of what's actually needed. BUT...how do you also maintain some degree of accountability? If timelines can perpetually slip due to changing requirements and there's no objective mechanism for identifying this, then things might not get delivered at all. Surely some delays in the delivery process are due to inefficiencies or poor prioritization -- deadlines help identify this. Now, to some extent the answer lies in hiring. The right blend of autonomy and individual motivation negate the productivity slip that might occur in an environment where it's easy to procrastinate. The right people in the right environment will self-police and police each other (in a healthy way). I appreciate deadlines as a mechanism for forcing a discussion about tradeoffs. If there's some cost to delaying things then I'm more likely to think carefully about taking on the associated work. This usually leads to better decisions. I (usually) avoid spurious refactoring and overzealous testing, and scrap features that are less important. So, rather than do away with deadlines entirely I think it's important to build up a culture that: * Avoids punitive patterns -- rarely should folks be held unaccountable for adjustments in the timeline. Unless it's a clear pattern, it's not the fault of the person. * Embraces (sometimes a lot of) discussion about deadline adjustments and the associated trade offs. There should be some friction to missing a delivery date, but not so much that it prevents us from doing the right thing. This is of course hand wavy and really hard to get right.
- commandlinefan 5y ago
  > rarely should folks be held unaccountable for adjustments in the timeline unaccountable? Was that a typo?
  - codeviking 5y ago
    Oops. Yes. Folks should rarely be held accountable for timeline slips. Thanks!
protomyth 5y ago
I still believe companies should approach software development like they are producing a TV show. Software development, as much as we try, is not an engineering process like widget production or bridge building. It is still by and large a creative process. I get the feeling a couple of show runners would have a better time of it than most classically trained managers.
- delaynomore 5y ago
  >Software development, as much as we try, is not an engineering process like widget production or bridge building. It is still by and large a creative process. I actually think it's the opposite. Majority of the software projects (IMHO) out there are exactly like bridge building. For the most part you adhere to the same engineering principles, and depend on the budget/requirement, have some room for creativity. Some bridges are masterpieces and will last more than a hundred years while some others could collapse at any time.
  - protomyth 5y ago
    Bridge building dates back to antiquity and has developed a rigorous knowledge base of tools, materials, and techniques. Software development cannot even pick a language or paradigm with less than a century of experience. We do bridge builders a disservice for thinking that we are in their league with big project engineering.
  - username90 5y ago
    The problem is that it takes 10 years to learn how to write software well. And after 10 years you no longer write software, you become a manager of people who are just beginning that process.
abeppu 5y ago
This points out several problems which management must not create. But because engineers cannot fix these, the other side of the same coins is having a checklist of mismanagement red flags which tell an engineer to find a new company.
lifeisstillgood 5y ago
I think he just invented Developer Anarchy https://www.youtube.com/watch?v=tIxHmsWCd7g https://www.youtube.com/watch?v=tIxHmsWCd7g Honestly I just call this Software Literacy.
grepLeigh 5y ago
To understand the angle of this article, I looked for what this site is selling: https://iism.org/training https://iism.org/training > We have a management problem! > How traditional management sabotages the bottom line > Developers are fine, management needs to change Folks who agree with these headlines & don't click away immediately seem more predisposed towards the offered product, which seems to be a mixed bag of developer-entrepreneur-leadership training that would make sense for a small, flat organization.
myohmy 5y ago
Their conclusion is a bit off. The WBS and GANTT charts are used for resource planning. I don't work for a unicorn so resource constraints mean that I actually need to plan, prioritize, and schedule work. If I do a bad job of that then my developers get laid off, we don't get paid for slack. One thing they miss is that managers manage expectations both up and down. People only get angry when you step outside of their expectations. I work in a PMP setting and I am up front in my project plan about how we're using PERT estimation (so they always look high), that we're dedicating time to testing, automation, and documentation, and explain why. Its straight up in scope. The client signed it. The CIO signed it. Problem solved. The one thing I find is that developers chronically underestimate. And that's something that I found going from a programmer to a project manager. I always thought about my code and never the back-and-forth communication with stakeholders, and the change requests, and all the little BS that inflates estimates. That's why I teach my programmers PERT estimation, because it forces them to think about what the doomsday scenario is. We've gotten pretty darn good at estimation these days, which is good because we are a consulting shop, so if we underestimate we don't get paid, or have to get a change request.
- NAHWheatCracker 5y ago
  There are managers like you, who understand estimation. Then there are managers like my former manager, who took a 2.5 year estimate from me and sold it to leadership as something we can do in 6 months. When he tells me the project got a green light, I pointed out that I also listed several risk factors that would be major blockers in the first 6 months. This manager was also the scrum master on the project, and proceeded to contribute nothing for the next 3 months. He was waiting around for a promotion to some sort of leadership/project management position. Luckily his replacement was a massive improvement. A year later and we were right on track for my original estimate but I lost all credibility in the org despite busting my butt to keep the project on the rails. It's not just engineers who are bad nor is it just managers. Both sides have to do their part and respect each other or it can go sour.
ess3 5y ago
Few cents from someone who moved into Engineering Management from Software dev in a high growth organisation. 30% Hiring for my team but also helping out for other teams. This also includes optimising our process etc. 15% Maturing and coordinating the tech org getting things like oncall routines in place or what forums do we need (or what should've just been an email) 20% Growing individuals through coaching and mentoring as well as finding opportunities for them to shine. 20% hands on teamwork usually being the one who asks stupid questions to ensure all uncertainties are brought up. 15% putting out fires I'm pretty happy with this division. I'm also very happy to also have a product manager and a tech lead in my team to avoid one person wearing all those hats.
lmilcin 5y ago
Unfortunately it is more like two way street. Bad managers putting blame on developers for "not doing their job" when they did not provide correct environment for developers to do their job well. Developers don't recognizing they are in fact making a lot of management decisions every day because of nature of they work and that they make poor job of it.
MelvinButtsESQ 5y ago
I can't help it: https://www.youtube.com/watch?v=fcIMIyQnOso https://www.youtube.com/watch?v=fcIMIyQnOso
deleted 5y ago
[deleted]
username90 5y ago
The main problem is that you get promoted for creating social solutions to technical problems. If you solve a problem by writing a great solution in code people will pat you on the back at best, if you do it by creating a plan, hiring people and delegating tasks you become a manager. "Managers are a force multiplier", well so are developers. A good developer can write programs that runs on thousands or even millions of machines delivering great value, thus there is no limit to how much value a developer can deliver. However since managers gets promoted by implementing social solutions they will always try to go that route. Of course you can do it wrong the other way and be too technical, but I doubt it happens often since managers holds so much more power than developers. Google and Facebook have about the right amount of technical focus, most companies are way less technical than that and suffers from it.
flippinburgers 5y ago
My "favorite" kind of manager: The project is running behind. A time extension is accepted by the big-wigs. The manager quite brain-fully increases the number of tasks that need to be completed in the newly allocated timeframe.
Tarucho 5y ago
Problem is computing is overstaffed with non-technical managers that believe programming is a thing for little employees. Enterprise Agile has made this situation worse.
ctoacademy 5y ago
Comes down to definition of autonomy. If you loosely define the problem to be solved, it is no wonder some take a different than expected approach. If you define the problem that needs to be solved correctly, then autonomy should work as team is likely to come up with better solution. Tech is R&D and creative and the conceptual models will be different amongst the stakeholders and team - the key is make sure everyone has the same model.

380 points by sidcool 5y ago

No but they can bear the blame until they burn out and afterwards be replaced by a fresh bundle of youngsters. That's how it usually goes at the companies I consult to clean the mess

villasv 5y ago

Every organizational problem is a management problem. I doesn't mean developers can't and shouldn't try to fix it. Concluding such article with "Developers are fine" is too cynic. For reference, at my org, management already does what it says it should do and already don't what is says what it shouldn't do. Still there are developers who need to step up their business understanding. Despite all the training, the stimulus, the right incentives, it is not natural for new tech/team leads to communicate well how technical challenges must translate into business decisions. This shit is hard and complex, stop trying to assign blame.

pdimitar 5y ago
I treat all such articles with the condition of "I am not saying this happens everywhere but it happens fairly often" -- which is also my experience. I've met several excellent managers and I have huge respect for them but seriously, they are rare. I am almost 20 years in the industry and I am not sure I've even met 5 of them.
- villasv 5y ago
  My point is not that good management is possible. The article drew conclusions to which my experience is a counterexample.

gregdoesit 5y ago

I have a theory on why we're seeing so much "bad management" for software engineers: most leaders at workplaces have not been engineers themselves at a company with a great engineering culture (I wrote about what I think this means [1]: it's all the high-growth small and large tech companies we know) The CEO, and the people under the CEO know and understand traditional, top-down management. Let the people with context and decision power make the big decisions, and pass this downwards. Works with finance, works with marketing, works with IT support, and should work with engineering as well... right? But it actually doesn't work with software engineers as well as it could. Or with designers. UX researchers. PMs... all these people would produce a magnitude more output when given proper context and autonomy. A few leaders read about this, and try giving autonomy. These results end up even worse than the status quo, as you can't just make it a free-for-all and expect it works overnight. And to prove this point: look at companies where the founder had worked at a high-performing company before. Before founding Twilio, Jeff Lawson spent years at Amazon (he was one of the first AWS PMs), and in his book Ask Your Developer, he writes about just how much this experience shaped him, and all the practices he adopted from Amazon. There's this really weird divide between "forward-looking tech companies"[2] who "get it", and everyone else. Which heavily benefits this first group. [1] https://blog.pragmaticengineer.com/the-developer-culture-test/ https://blog.pragmaticengineer.com/the-developer-culture-tes... [2] https://news.ycombinator.com/item?id=25717390 https://news.ycombinator.com/item?id=25717390

jbverschoor 5y ago
It's not "traditional". It's common sense. You can't let an X company be run by someone without any affinity of X. Would you let a painter do surgery on you?
- Jenk 5y ago
  > Would you let a painter do surgery on you? False comparison. It should read "Would you let a painter _manage the surgeons_ who will operate on you?" Having worked in the healthcare industry - the answer to that might surprise you.
  - pdimitar 5y ago
    To be fair, I am pretty sure most people here in HN wouldn't be at all surprised. We're very used to watching laymen having to manage potential millions of revenue.
  - jbverschoor 5y ago
    I guess it's the right example, because healthcare is a mess as well
Jenk 5y ago
Crappy management begets crappy managers. Agreed. I have a counter/supplementary theory that it is just as disruptive to assume a good developer will be a good leader or manager, too. Rant time (aimed at no one in particular, especially not parent comment): Managing is a very different skillset. There needs to be some significant knowledge of the industry at large, the specific domain that is relevant to your biz, and "generic" (for lack of a better phrase) management skills (i.e., communication and management of the squishy bits of your org that show signs of sentience and sometimes speak) I've lost count the number of times I've heard colleagues say "They are such a bad (technical) manager, they'd never be able to do what I/we do." and have responded with "They don't need to. That's why they pay you." I get very tired of this "debate" that it is management _versus_ IC/developer/engineer/worker. I also strongly believe a lot of what is perceived as "top-down" management is harbored by a "bottom-up" resentment - or just plain resisting authority. You are a team, so work together. I also hold the opinion that if your organisation has this mindset ("versus") within then you have a much bigger problem than what is presented at face value.

qrbLPHiKpiux 5y ago

So, developers want a blank check, is what I’m reading?

codebolt 5y ago

As a developer, I got some valuable insights from the book Extreme Ownership by Jocko Willinck. I think particularly the principles of "leading up the chain" is crucial when you're a developer with managers who don't have the necessary context of understanding to make optimal decisions on their own. Perhaps not as easily applied in all company cultures. But in my case, it gave me the confidence to voice my opinion on a few critical issues of strategic importance over the past few years. This year I was promoted to "system responsible" (basically lead dev with technical responsibility for the system) and I think that was in part an acknowledgment of my ability to take ownership of a situation and helping to make sure sound a sound strategy is in place.

plasma 5y ago
I can also recommend this book (it’s on Audible too and a great listen).
proc0 5y ago
Check.

Ozzie_osman 5y ago

> In most companies, management is actually to blame for deliberately isolating engineers from discovering the customer's needs. News flash! Developers actually like the idea of figuring out and fulfilling needs with epic software solutions and are fairly neutral-to-downright-annoyed at spending their time creating something that no customer wants. I agree with the first statement but disagree with the second. Yes, management is often at fault for not involving or engaging developers. That said, I've seen many really solid developers be motivated by solving complex technical challenges instead of work that actually creates business/product value. Of course, it's management's responsibility to harness that energy and align it with creating value... But just saying, a lot of really smart people are driven more by intellectual challenges than product impact.

jdowner 5y ago
I can say that this is true for me. I like helping people but I get my motivation from feeling that I have solved a problem well. Maybe it is the nature of the kind of software I tend to write, but I'm not all that interested in whether it is used by millions of people or purportedly helps a bunch of people. That's nice, it's just too far removed from the work for me to be motivated by it. The bonus is that I also don't have an issue if something I've worked on is scrapped for whatever reason, and I know that that is something that some people have a hard time coping with.
Aeolun 5y ago
Technical challenges that are actuslly used beat out technical challenges that are just for fun though.
- UncleMeat 5y ago
  That depends on the engineer. There are absolutely people who aren't motivated by impact whatsoever.
  - lanstin 5y ago
    And their coworkers will be able to find nice complex isolated problems for them to solve. That isn’t a problem in for the group in general, because that is like finding a really nice tool that you can use however you like. And most any domain can use brilliant solutions, if you think about it for a few days.

kbmunchkin 5y ago

After 12 years of software development, I've come to the conclusion that software managers are not needed. From what I can tell, they have meetings, try to get people to work more, and approve time off. The best team I've been on didn't have a manager. The lead developer handled communication with the IT Director about project status; and that wasn't very often. We had no meetings, or KPI goals, and other such nonsense. That is, until the company was bought. Everything changed after that and traditional management took over. Most people left within a year.

Aeolun 5y ago
The best teams I’ve been in have been the ones where there was no filter between the developer and the client. The more filters, the harder everything becomes.
- swader999 5y ago
  Co-located with your users for the win. If there's such a thing as a silver bullet in this space this is it.
  - Mauricebranagh 5y ago
    Yeh Back in 94 I and another developer got flown up to Edinburg and delivered using RAD/DSDM in a month what a another traditional team said would take 2 years. One of the other ideas at the times was a custom BT version of HTML - that got stamped on very had by the Labs thank god.
- alistairSH 5y ago
  Perhaps, but that doesn't scale well. My previous role, I served 100s of clients, each with 1000s of end-users. If those users had direct access to my development team (5 devs, 2 test engineers, 1 BA) they'd spend the entire day fielding requests and get nothing done. So, to avoid that, you add a product management team. And an SDM, who acts an umbrella over the dev team to prevent shit raining down on them from tech support, product management, sales, etc. I suppose that's the key - if an SDM doesn't see themselves as a shit umbrella, they aren't doing their job. That's not their only role, but from the developers' perspective, it's perhaps the most important. Edit - the team did interact with customers via various channels, but it was more controlled than "unfiltered". We had a forum where both sides could communicate (though the BA typically did the lion's share of that work from our end). We also had periodic beta review meetings with select customers. And of course, when tech support issues got to our level, we were often on the phone, VPNed into their systems, etc. But, between the BA and I, we triaged most inbound communication, and there was zero expectation a developer would respond unless specifically asked by me or BA (though they were free to do so if they wanted - most preferred not to do so).

sidlls 5y ago

It's not as straightforward as the author of this article suggests. Not all engineers do care about whether their work serves the company's interests, and some (many?) will go out of their way to square a round hole, so to say, to justify some itch they wanted to scratch. I know the HN take on things is that the best engineering management comes from people who are/were engineers in the past. But, respectfully, I just have to disagree that they're any better, especially if they come from "big tech" (e.g. FAANG). There's a real (terrible) tolerance for vanity projects, gamesmanship, and ego stroking that comes from that lot, IME.

jph 5y ago

Developers have opportunities to improve management by increasing management-visible headlines about user goals, and decreasing management-visible headlines about implementation details such as UI, WBS, wireframes, flowcharts, and tech. Try this thought experiment: Imagine you have team task list with headlines such as "Add red button to top of home page". Imagine rewriting the headlines such as "Customer wants to contact us" and similar kinds of user stories. When managers continually see headlines with user emphasis, and do not see headlines with implementation details, then management improves and developer autonomy improves, because both groups are looking toward users. It turns out focus on user stories can help significantly, even more than some developers might intuit. Look at your task board headlines and the opening paragraphs of your management-visible writing-- can you improve your writing to emphasize user goals?

ClumsyPilot 5y ago
This is such a good point, Its a bit like how developers neglect to write documentation, developers often neglenct to communicate effectively or create 'communication artefacts' like diagrams, etc that make their work more comprehensible
- jgeada 5y ago
  Interesting that developers are expected to do all this other ancillary work that is the remit of other professions. How often do we expect the technical writers, marketing, sales, management, etc to also do their share of writing the code? I too would like to do lots less work and have other professions help out and be available for the scapegoat game when it goes wrong. Documentation not up to par, blame developers. Marketing failed to achieve goals, ...
  - ClumsyPilot 5y ago
    I think the person doing much of the communication has to be the developer, noone knows what's happening in hid system better than he does. But that must be a separate activity pruoritised and with time allocated. Lawyers have to do many anciliary activities, but they are given time to update their qualifications, etc by their employer

whoomp12342 5y ago

Can I point out the fact that this article compares software developers to auto workers trying to explain the problem and then highlights failed management strategies as a fact that software development is nothing like manufacturing, saying " and if I ever run a factory, I'm gonna use it! But it has no place in software projects." I dont disagree with this article in general but please dont contradict yourself.

commandlinefan 5y ago
I don't think he really contradicted himself - what he's saying is that auto workers fell behind because management was trying to manage them like farm workers when they weren't, and that software is falling behind because managers are trying to manage them like factory workers when they aren't.

jillesvangurp 5y ago

People self select to be in these situations and they can self select themselves out of it too (by changing employer). There are lots of not so great engineers working in not so great companies. Good engineers tend to have options to improve their work situation and most of them do. Sometimes they are happy to take the money for an easy job as well. However, I see a lot of issues that have also to do with a few factors that are hard to control: 1) programmers are mostly young. There are older programmers and they don't actually disappear (I'm one of them). However, the number of programmers keeps on doubling every five years meaning that at the ripe age of 46, I've experienced about five doublings meaning there are about 16-32 x more juniors aged 20-25 active than people my age. I work with a lot of people half my age currently. 2) Most people aged 30 would count as "senior" because they are relatively scarce and more experienced than most programmers. I got that label slapped on me around that time. That's nearly 17 years ago. I did not have a lot of experience at the time and I've certainly learned a lot since then. This is a common pattern in our industry. We have a lot of very junior senior engineers rediscovering a lot of things about software engineering every generation because there are very few proper seniors around to learn from. I'm usually the oldest person in a project and that's been the case for almost ten years for me. Yet, I know lots of engineers my age as well and most of them are in a similar situation. 3) Scrum adds roles to teams that I would classify as junior management. Product owner or scrum master would be good examples of job descriptions that end up like that. I've experienced more than a few PMs that were effectively on their first job and scrum masters that had little more than a two day training + a hand shake as management background (been there, done that). Junior management and junior "senior" engineers adds up to very predictable issues. Sometimes it works. Mostly it doesn't. The problem is not the process but a lack of experience on both sides. Hiring more people makes it worse. 4) Proper seniors are expensive but being old doesn't necessarily mean you are very good. I know I have to work hard to keep up with younger people. There's something to say for removing mildly burned out cynical forty somethings from your team. I've had to make calls like that to resolve a few toxic situations. Putting an old person in charge does not necessarily solve your problem either. 5) Software engineers generally lack soft skills needed for management and there's a lot of pressure on people to get promoted to their level of incompetence. Once that happens they are easy to manipulate by senior management. Large organizations with a lot of middle management that isn't so great fall victim to this. It' a classic A's hire A's and B's hire C's. Replace hire with promote and you have basically a template for how great companies almost inevitably turn mediocre. The A's tend to leave when that happens. 6) If you think forty something male programmers are scarce, try finding a forty something female one. They are a small minority in any age group but the golden combination of being forty plus, female, and still doing actual engineering is super scarce. As in: I struggle to name a single person that qualifies as that. Most women I know that age have long stopped being engineers and have turned manager or changed career entirely. Women generally are better at soft skills and make great managers so it's not the worst thing. But there's also sexism that drives them away from engineering prematurely before they've had a chance to become really good at that. I know more than a few women that have hit a glass ceiling where people just naturally assume a lack of technical skills because of gender bias. If you have the option, balance your teams as much as you can and things will get better. Resist the urge to put the girls in charge because they are girls. That's a form of sexism that helps no-one. Instead promote them to being tech lead, senior engineer, principal engineer, etc. They'll make better managers when they are ready for that career move. Better still, they might attract some junior female talent. Women generally know where the good jobs are. I've been in a few places that had good policies on that front and it makes a difference.

forinti 5y ago

The best manager I ever had really just left the team to do its job. I think we might only really need management on a higher lever for large projects. We certainly don't need Project jockeys for managing very small teams. As with many things in software, we don't have the maturity to clearly identify where the complexity and overhead are needed. A project manager for a 3 person team is like a bloated multilayer web app that gets 50 users a day. It's just superfluous.

agentultra 5y ago

It's not for lack of trying. A large part of developer culture is spent on working against or around bad management. Agile, XP, scrum, etc. Piles of books on it. Youtube channels and blogs dedicated to advice on how to navigate bad management. Bad management is everywhere. We humans are not very good at managing knowledge work. Worse at software in my experience. And all too often I see software developers taking the blame or blaming themselves. A good deal of software errors are enabled by poor management practices. When you let off the management reigns and trust developers to understand the importance and impact of their decisions you get a lot better results.

thrower123 5y ago
The insidious part is that every effort to work around bad management of this type is captured by management, and twisted, corrupted, and festered until it becomes yet another torture inflicted by management. Agile would be just fine, if it was the bottom-up, developer-focused scheme that the manifesto writers and True Scotsmen claim it to be. Unfortunately, it's been co-opted, and we end up with interminable daily standups that are driven by line managers, or by yet another useless person who bought a Scrum Master certification, and exist solely for developers to justify themselves and kowtow in self-abasement. Likewise with the whole cavalcade of infantilizing sprint planning meetings and planning poker and retrospectives and meeting after meeting after meeting imposed as part of a holy Process, that the company spent tens of thousands of dollars having consultants implement.
- vbtemp 5y ago
  Agile is exactly the corporate management hell it claims it was out to solve.
ornornor 5y ago
> Piles of books on it. Youtube channels and blogs dedicated to advice on how to navigate bad management. Can you recommend some? I’m at a point in my career and at an organization where this is a matter of survival way more than actual competence.

commandlinefan 5y ago

> Software development is much closer to creating a new factory than running an existing factory This has been known, and ignored, for at least 30 years now.

jimbokun 5y ago
Known among software people, non-software people often need to be informed of this.
- commandlinefan 5y ago
  Maybe "ignored" wasn't the right word... rejected might be a better term.

travisgriggs 5y ago

Wow. So much of this article resonates with me. Strong parallels with the recent re-debate of "bullshit" jobs. I have the privilege of working in a pretty low management shop, but sometimes it rears its ugly head and I chafe at it. Of recent I've observed that not everyone is like me in this regard. Even though humans don't like being managed, they also don't like taking risks. And for some people, the ability to offload risk, accountability, and liability to a scapegoat figure that is inconvenient to deal with at times (e.g. a bullshit manager) is actually a purchase they're willing to make. It's ironic to me, that years ago, the world had lots of clerks (people who kept the wheels of process logistics rolling) and less managers. Today, there are fewer (almost no) clerks, but lots of managers. Look at what most of your manager does, and see if (s)he isn't mostly just a clerk that collectively figured "manager" pays better.

orsenthil 5y ago

All problems can be fixed. How you fix them is relative to what are you trying to optimize for. If the management is bad to development culture, the developers can go elsewhere. If the leaders (including developers and management) is bad with decision making, the market will fix it.

managementwoes 5y ago

When a project is delivered on time, within budget, and produces the expected value for a company, it is not necessarily the result of "good management". This is why "bad managers" survive in our industry, far too often a manager's performance is measured on the success of the projects they are "accountable" for. I believe the responsibility of a "manager" is to provide support to the people they "manage", which can take on many forms. e.g. - Hiring additional staff to handle the current workload at the desired cadence. - Influencing the stake holders so the business priorities benefit their employees (and indirectly the company). - Providing emotional or moral support to their staff. - Being a source of motivation through exuding passion, or setting an example that their staff aspire to.

k__ 5y ago
Reminds me of a small-ish company I worked for. All promotions were based on the fact that the original person holding the role left. You could end up as head of r&d with being just out of college for two years.

nickthemagicman 5y ago

I found business analysts and project managers to be wonderful. Managers are just useless layers of bureaucracy and their job could easily be automated. MBA programs are the easiest of all of the graduate degrees. But because of good old boy networks, MBA program networking, and mangers hiring other managers the parasite continues to spread.

steveBK123 5y ago
Agreed. PMs/BAs are going out of style in favor of "product managers" and it's a huge mistake. Most of my friends who are in technical lead roles would kill to have a dedicated PM to do the parts of their job they don't like and aren't great at. Given the pay differential, it would be a good trade for most employers to do this as well...
- nickthemagicman 5y ago
  I've only had the luxury of working for one company that had BAs. But it was absolutely wonderful. They would communicate with the stakeholders and users and other groups to flesh out the specification. And they would bring the specification to the developers almost fully formed with what we had to do. So from there we just were able to just engineer! Which is really what our specialty is. It was heavenly to me, because I find the most painful part of this career is trying to squeeze, schmooze, and cajole a coherent specifications out of stakeholders and users. I firmly believe a good project manager can be the difference between a projects success and failure.

ineedasername 5y ago

Just another story that essentially says everything would be great if only the developers ran everything. It's an over simplified view of how large organizations function. It is also a story the pretty much every group in an organization tells themselves at some point: from HR's perspective things would be great if the company just let them if the company let them pursue their vision of proper talent acquisition. The sales team believes they're most important because without them there's no revenue and they understand customers the best because that's one if their closest contacts. And so on. The truth is that no one group would accomplish much if they were the only ones in charge. In reality, there should be a seat at the table for all of the groups. Absolutely developers should be in the mix for understanding customer needs and helping guide things appropriately. But developers are no more inherently capable of understanding those needs than anyone else, and in fact a non technical view is just as important when the target audience is not just technical folks. An organization will fail when pretty much any one of its groups is sufficiently bad at their job, and will rarely succeed just because one group is good at theirs. But the "if only developers ran things" trope is old and worn and wrong.

nine_zeros 5y ago
> Just another story that essentially says everything would be great if only the developers ran everything. It's an over simplified view of how large organizations function. Just another manager who wears their ego on their sleeves. A lot of developers handle EVERYTHING (including politics) in modern companies except promotions and performance reviews. There is no real need for a manager if devs are doing everything.
- kenjackson 5y ago
  > A lot of developers handle EVERYTHING (including politics) in modern companies except promotions and performance reviews. There is no real need for a manager if devs are doing everything. Which modern company does this? The closest that jumps to mind is Valve.
- ineedasername 5y ago
  Wrong: I'm not a manager. Check my profile, you'll see the area I work in. I have no interest in being a manager because I understand the different skill sets and what I enjoy doing. But if we're bringing the issue of ego into it, there's yours right on display thinking developers know everything. Well, consider this: If you were right, there'd be a lot fewer startups with great ideas that flop even with developers in charge, but they fail because they can't execute on their idea by also running an organization properly. Developing code and running an organization are different skill sets, and not many people have both.

taeric 5y ago

Managers shouldn't be there to manage the people directly. They are there to manage the processes and environment. If a process isn't working, step in and prod it. Remove if necessary. Add where necessary. Sometimes repeatedly. That is, add then remove them add the same process. To that end. Developers are there to manage the code. Apply the same rules. Don't be afraid to try last year's failed strategy. Or to take out last year's success.

codeviking 5y ago

A lot of the ideas communicated resonate with me. The estimation process doesn't work well, and creates friction when things change that can interfere with the delivery of what's actually needed. BUT...how do you also maintain some degree of accountability? If timelines can perpetually slip due to changing requirements and there's no objective mechanism for identifying this, then things might not get delivered at all. Surely some delays in the delivery process are due to inefficiencies or poor prioritization -- deadlines help identify this. Now, to some extent the answer lies in hiring. The right blend of autonomy and individual motivation negate the productivity slip that might occur in an environment where it's easy to procrastinate. The right people in the right environment will self-police and police each other (in a healthy way). I appreciate deadlines as a mechanism for forcing a discussion about tradeoffs. If there's some cost to delaying things then I'm more likely to think carefully about taking on the associated work. This usually leads to better decisions. I (usually) avoid spurious refactoring and overzealous testing, and scrap features that are less important. So, rather than do away with deadlines entirely I think it's important to build up a culture that: * Avoids punitive patterns -- rarely should folks be held unaccountable for adjustments in the timeline. Unless it's a clear pattern, it's not the fault of the person. * Embraces (sometimes a lot of) discussion about deadline adjustments and the associated trade offs. There should be some friction to missing a delivery date, but not so much that it prevents us from doing the right thing. This is of course hand wavy and really hard to get right.

commandlinefan 5y ago
> rarely should folks be held unaccountable for adjustments in the timeline unaccountable? Was that a typo?
- codeviking 5y ago
  Oops. Yes. Folks should rarely be held accountable for timeline slips. Thanks!

protomyth 5y ago

I still believe companies should approach software development like they are producing a TV show. Software development, as much as we try, is not an engineering process like widget production or bridge building. It is still by and large a creative process. I get the feeling a couple of show runners would have a better time of it than most classically trained managers.

delaynomore 5y ago
>Software development, as much as we try, is not an engineering process like widget production or bridge building. It is still by and large a creative process. I actually think it's the opposite. Majority of the software projects (IMHO) out there are exactly like bridge building. For the most part you adhere to the same engineering principles, and depend on the budget/requirement, have some room for creativity. Some bridges are masterpieces and will last more than a hundred years while some others could collapse at any time.
- protomyth 5y ago
  Bridge building dates back to antiquity and has developed a rigorous knowledge base of tools, materials, and techniques. Software development cannot even pick a language or paradigm with less than a century of experience. We do bridge builders a disservice for thinking that we are in their league with big project engineering.
- username90 5y ago
  The problem is that it takes 10 years to learn how to write software well. And after 10 years you no longer write software, you become a manager of people who are just beginning that process.

abeppu 5y ago

This points out several problems which management must not create. But because engineers cannot fix these, the other side of the same coins is having a checklist of mismanagement red flags which tell an engineer to find a new company.

lifeisstillgood 5y ago

I think he just invented Developer Anarchy https://www.youtube.com/watch?v=tIxHmsWCd7g https://www.youtube.com/watch?v=tIxHmsWCd7g Honestly I just call this Software Literacy.

grepLeigh 5y ago

To understand the angle of this article, I looked for what this site is selling: https://iism.org/training https://iism.org/training > We have a management problem! > How traditional management sabotages the bottom line > Developers are fine, management needs to change Folks who agree with these headlines & don't click away immediately seem more predisposed towards the offered product, which seems to be a mixed bag of developer-entrepreneur-leadership training that would make sense for a small, flat organization.

myohmy 5y ago

Their conclusion is a bit off. The WBS and GANTT charts are used for resource planning. I don't work for a unicorn so resource constraints mean that I actually need to plan, prioritize, and schedule work. If I do a bad job of that then my developers get laid off, we don't get paid for slack. One thing they miss is that managers manage expectations both up and down. People only get angry when you step outside of their expectations. I work in a PMP setting and I am up front in my project plan about how we're using PERT estimation (so they always look high), that we're dedicating time to testing, automation, and documentation, and explain why. Its straight up in scope. The client signed it. The CIO signed it. Problem solved. The one thing I find is that developers chronically underestimate. And that's something that I found going from a programmer to a project manager. I always thought about my code and never the back-and-forth communication with stakeholders, and the change requests, and all the little BS that inflates estimates. That's why I teach my programmers PERT estimation, because it forces them to think about what the doomsday scenario is. We've gotten pretty darn good at estimation these days, which is good because we are a consulting shop, so if we underestimate we don't get paid, or have to get a change request.

NAHWheatCracker 5y ago
There are managers like you, who understand estimation. Then there are managers like my former manager, who took a 2.5 year estimate from me and sold it to leadership as something we can do in 6 months. When he tells me the project got a green light, I pointed out that I also listed several risk factors that would be major blockers in the first 6 months. This manager was also the scrum master on the project, and proceeded to contribute nothing for the next 3 months. He was waiting around for a promotion to some sort of leadership/project management position. Luckily his replacement was a massive improvement. A year later and we were right on track for my original estimate but I lost all credibility in the org despite busting my butt to keep the project on the rails. It's not just engineers who are bad nor is it just managers. Both sides have to do their part and respect each other or it can go sour.

ess3 5y ago

Few cents from someone who moved into Engineering Management from Software dev in a high growth organisation. 30% Hiring for my team but also helping out for other teams. This also includes optimising our process etc. 15% Maturing and coordinating the tech org getting things like oncall routines in place or what forums do we need (or what should've just been an email) 20% Growing individuals through coaching and mentoring as well as finding opportunities for them to shine. 20% hands on teamwork usually being the one who asks stupid questions to ensure all uncertainties are brought up. 15% putting out fires I'm pretty happy with this division. I'm also very happy to also have a product manager and a tech lead in my team to avoid one person wearing all those hats.

lmilcin 5y ago

Unfortunately it is more like two way street. Bad managers putting blame on developers for "not doing their job" when they did not provide correct environment for developers to do their job well. Developers don't recognizing they are in fact making a lot of management decisions every day because of nature of they work and that they make poor job of it.

MelvinButtsESQ 5y ago

I can't help it: https://www.youtube.com/watch?v=fcIMIyQnOso https://www.youtube.com/watch?v=fcIMIyQnOso

deleted 5y ago

[deleted]

username90 5y ago

The main problem is that you get promoted for creating social solutions to technical problems. If you solve a problem by writing a great solution in code people will pat you on the back at best, if you do it by creating a plan, hiring people and delegating tasks you become a manager. "Managers are a force multiplier", well so are developers. A good developer can write programs that runs on thousands or even millions of machines delivering great value, thus there is no limit to how much value a developer can deliver. However since managers gets promoted by implementing social solutions they will always try to go that route. Of course you can do it wrong the other way and be too technical, but I doubt it happens often since managers holds so much more power than developers. Google and Facebook have about the right amount of technical focus, most companies are way less technical than that and suffers from it.

flippinburgers 5y ago

My "favorite" kind of manager: The project is running behind. A time extension is accepted by the big-wigs. The manager quite brain-fully increases the number of tasks that need to be completed in the newly allocated timeframe.

Tarucho 5y ago

Problem is computing is overstaffed with non-technical managers that believe programming is a thing for little employees. Enterprise Agile has made this situation worse.

ctoacademy 5y ago

Comes down to definition of autonomy. If you loosely define the problem to be solved, it is no wonder some take a different than expected approach. If you define the problem that needs to be solved correctly, then autonomy should work as team is likely to come up with better solution. Tech is R&D and creative and the conceptual models will be different amongst the stakeholders and team - the key is make sure everyone has the same model.