[HN Gopher] Developers can't fix bad management (2020)
___________________________________________________________________
Developers can't fix bad management (2020)
Author : sidcool
Score : 317 points
Date : 2021-06-10 09:39 UTC (13 hours ago)
(HTM) web link (iism.org)
(TXT) w3m dump (iism.org)
| Ozzie_osman wrote:
| > 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.
| twoquestions wrote:
| > 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.
|
| Complex technical challenges create value for the _developer_ ,
| as it's fun solving problems like that. If management doesn't
| communicate the end-user's needs/wants and how the product
| helps them, even valuable work can feel like pushing up
| Sisyphus's boulder, so working on fun stuff at least creates
| value for you rather than work that appears to be purely for
| the leadership's vanity.
| lanstin wrote:
| For people that are in software because they love it, rather
| than for fame and fortune, in fact love the fact that the
| maths side of your brain can make stuff happen for people.
| For technical challenges, nothing beats algebraic topology or
| QFT, but with software you can make stuff that is real, and
| amaze and deight your family. The problem is management's
| persistent blindness to the reality of their technology and
| development technology. The non-technical folk will hear "we
| can't add this new feature without touching dozens of risk
| places in the code" and not understand the fact that this is
| extremely risk and is an urgent problem. they seem to think,
| hire someone that can remember the dozens of places to
| change" and make for awesome failure analyses where 36 call
| points where changed but the 37th was missed and . . . Etc.
|
| If you think the software you are making is useless, you
| should find a different position. Life is short, and it's
| thrilling to be responsible for software that people use and
| enjoy.
| Aeolun wrote:
| Technical challenges that are actuslly used beat out technical
| challenges that are just for fun though.
| UncleMeat wrote:
| That depends on the engineer. There are absolutely people who
| aren't motivated by impact whatsoever.
| lanstin wrote:
| 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.
| jdowner wrote:
| 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.
| commandlinefan wrote:
| > 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 wrote:
| Known among software people, non-software people often need to
| be informed of this.
| commandlinefan wrote:
| Maybe "ignored" wasn't the right word... rejected might be a
| better term.
| abeppu wrote:
| 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.
| whoomp12342 wrote:
| 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 wrote:
| 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.
| managementwoes wrote:
| 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__ wrote:
| 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.
| jillesvangurp wrote:
| 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.
| encloser wrote:
| Wonderful comment. Mirrors a lot of what I've experienced
| directly or indirectly in the industry.
|
| I'd add that mid-sized and up companies are usually not
| homogeneous. There are usually good and bad leaders, managers,
| and developers to be found within them. You can have a great
| experience in one part of a company and a horrible one in
| another part.
|
| Another thing that I've found is that there is no "one true
| way" for a team to operate. I have found that what works best
| is to lean into a methodology that meets your business partners
| wants/needs and hire people that work well in that environment
| in that mode. Be it highly formalized and layer ITIL, super
| agile kanban+devops, or somewhere in between.
| commandlinefan wrote:
| > can self select themselves out of it too (by changing
| employer)
|
| ... who's exactly like the old employer because everybody is
| following the same playbook.
| forinti wrote:
| 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.
| codeviking wrote:
| 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 wrote:
| > rarely should folks be held unaccountable for adjustments in
| the timeline
|
| unaccountable? Was that a typo?
| codeviking wrote:
| Oops. Yes. Folks should rarely be held _accountable_ for
| timeline slips.
|
| Thanks!
| kbmunchkin wrote:
| 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.
| amarant wrote:
| While I see your point and get where you're coming from, I
| think it would be made explicit that "management isn't needed"
| is a gross oversimplification that is only possibly valid below
| a certain threshold of company size. I currently work for a
| very large international company and none of the things we do
| would be even possible without management.
|
| We're also lucky enough to have pretty good management, at
| least locally in my department, I haven't really been exposed
| to the higher levels of decision-making (which is a sign of
| good management IMO, that stuff is mostly irrelevant to me)
|
| I have admittedly less experience than you, (~10yrs) but from
| what I've seen, my conclusion is that really bad management is
| worse than no management at all, fairly bad management is about
| as bad as no management at all(and from here can the opinion
| that management isn't needed really form in developers head)
| and good management is way better than no management at all.
|
| I also think that software/tech management is a different beast
| from basically all other types of management. Experienced
| managers from other sectors tend to fall in one of the first
| two categories above in my experience.
|
| Good managers are perceived from the developers point of view
| as someone who just helps organise tasks, and help you find the
| right person to talk to if you need something from outside your
| team.
|
| In reality of course they do lots of other stuff too, but those
| things mostly shouldn't bother the developers IMO.
|
| Never should a manager ever act as a go-between. Doing that
| puts you firmly in the "worse than no management" category of
| managers
| gknoy wrote:
| > The best team I've been on didn't have a manager
|
| I feel exactly oppositely. The best teams I've been on have
| been ones where the manager has a strong focus on being a crap-
| umbrella for the team, sheltering us from anything coming from
| above, being an advocate for our needs, and a fierce seeker of
| true requirements for the projects that our team needs to work
| on.
|
| I think I would be very anxious being on a team that didn't
| have some manager who took seriously the role of sheltering and
| nurturing the rest of us. It's obviously not an easy job to do
| well (else we wouldn't have had bad management experiences).
| jollybean wrote:
| Of those 12 years, did you spend any time in any other role?
|
| Like manager, or director, product, product marketing?
|
| The world looks very different from there.
| Aeolun wrote:
| 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.
| alistairSH wrote:
| 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).
| andrewclunn wrote:
| Perhaps it shouldn't scale well. Perhaps software (being
| infinitely reproducible) doesn't require economy of scale
| the way other things might, and thus having a small close
| nit team of developers is optimal for almost all projects
| and companies.
| swader999 wrote:
| 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 wrote:
| 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.
| technofiend wrote:
| I know agile and scrum and so on carry a lot of baggage these
| days but what you're describing is Less Agile. You flatten the
| org back out, create product teams that pull from a single
| common backlog and developers interface directly with their
| customers. That's not even the most controversial part! You
| also do away with pay tied to individual goals: everyone
| succeeds or fails together and are paid the same way.
|
| https://less.works/less/framework/index
| swader999 wrote:
| You get what you measure and if you track performance and
| features individually you get less collaboration and gaming
| of the points.
| slumdev wrote:
| I liked this until everyone got paid the same. That's the
| fastest way to lose all of the people who can get more
| elsewhere. And it's not going to be the laggards who jump
| ship...
| technofiend wrote:
| Right? I did mention it's controversial.
| [deleted]
| Mauricebranagh wrote:
| Then the lead developer is the manager
| sudeepj wrote:
| One factor I think is span of control. If the director you
| mentioned starts getting project statuses from 15+ teams then
| the director might not scale. The director will not be able to
| scale for things like appraisals, burning issues, hiring.
| lummm wrote:
| I think below a certain threshold of competence, a manager will
| negatively impact the productivity of a team mostly by eroding
| any ability to focus on a single task at a time. A good manager
| should shield the team until it is appropriate from the very
| things a poor manager would be dumping on the team as they
| arise.
| Jenk wrote:
| > The lead developer .. was your manager.
| hamstergene wrote:
| I bet you would hate to spend 4+ hours per day in negotiation
| meetings, stacking up plans and writing reports, some days not
| even having time to start working on development tasks. You'd
| probably give all this to someone who wants and has experience
| to do it, someone like...a manager?
|
| If your lead dev didn't have to spend that much then I'm afraid
| that experience does not extrapolate on what larger companies
| do; if they did then I think you're missing the elephant in the
| room that the lead dev was de-facto the manager at the expense
| of their direct duties.
| oytis wrote:
| If that was true developers would make their living just by
| sitting in front of their personal laptops and coding. Instead
| they tend to apply for jobs at companies that have a lot of
| managers
| jpz wrote:
| Sounds like your experience is with small organisations.
| Management is required in large enterprises.
| dbsmith83 wrote:
| Exactly. Once the number of stakeholders crosses a certain
| threshold, your lead developer will be so busy with them that
| they will essentially just become the manager because they
| wouldn't have any time to code.
| valenterry wrote:
| What if the company hires someone dedicated for this role
| who... does not report to the lead developer but works with
| them?
| JohnWhigham wrote:
| Soooo...a manager?
| redleggedfrog wrote:
| I've been programming professionally since 1993, and I can tell
| you that some of the software managers I've have had been
| invaluable. When they are good they can be very propulsive. I
| don't necessarily have time to collect up all the different and
| sometimes contradictory specs from the product owners and make
| sense of them. When the manager is technical and can do this
| for you it's golden.
| jimbokun wrote:
| > From what I can tell, they have meetings, try to get people
| to work more, and approve time off.
|
| Do not under appreciate the importance of managers attending
| meetings, because a good manager attends those meetings so the
| devs don't have to. A good manager of developers seeks to
| shield her developers from the busywork and politics imposed by
| the larger organization so they can be as productive as
| possible.
| ipaddr wrote:
| After 20 years I realize managers are important to keep other
| managers away. If you have ever worked without a manager in a
| department you become the manager as other departments will
| need someone to meet with someone. More importantly secret
| deals, backstabbing and positioning are going on above you.
| Your department might be chopped up next, you need someone to
| fight those battles.
|
| Project managers are a different story.
| kannanvijayan wrote:
| I'm coming up on 15 years of professional career in software
| (development experience being 25 years or so).
|
| In small projects, a lack of managers can be pretty effective
| when there is good team cohesion and lack of conflicts over
| priorities and expectations.
|
| In larger projects and teams, where your team has to interact
| with other teams and navigate competing pressures within a
| larger organization, while still delivering on internal goals
| and keeping turnover reasonable.. managers are crucial.
|
| The best managers make you feel like there is no manager. They
| run interference for you. They talk to you, understand your
| individual priorities as a developer (project priorities as
| well as career priorities), and coalesce that information
| across their entire team to quietly craft a path forward that
| preserves cohesion and effectiveness and productivity and
| happiness. They also communicate progress to higher ups, and
| interpret (to the executives) the day-to-day operations with
| relation to broader organizational goals.
|
| Managers are the interface between larger organizational
| priorities and a team's individuals. For a company, managers
| serve the role of both implementing policy top-down, as well as
| understanding operational dynamics from the bottom up and
| communicating it to the higher-level positions in the org.
|
| They are fundamentally a structural necessity once you step
| beyond a certain scale of project or product or company.
|
| My personal thoughts on managers used to be closer to yours,
| but it has evolved over time. These days, I'm more inclined to
| think that _everyone should get an opportunity to be a
| manager_. Maybe even a structure where management roles are
| cycled between different people on the team with a willingness
| to take on the role. I think more developers need to understand
| how difficult good management is, and to get a personal
| exposure to that problem space. I think it would make
| developers into better developers.. who, rather than reacting
| blindly to their local perception of the symptoms of management
| (poor or good), get a firsthand view of the other side, and
| learn to better interact with it in the future.
| bradstewart wrote:
| > The best managers make you feel like there is no manager.
| They run interference for you.
|
| This is the most important thing, and its hard to recognize
| as its invisible to the developers. "Do I need a person
| running interference so I can focus and get stuff done?" is
| also a useful metric to decide if/when you need a manager.
| klenwell wrote:
| > everyone should get an opportunity to be a manager
|
| One way to test drive being a manager: read the Ask A Manager
| column (https://www.askamanager.org/) for a few days or
| browse the archives. Read the question submitted by the
| reader, consider how you would deal that problem, then
| compare your response with Alison's (and the commentors
| below.)
|
| Yes, most the problems are not technology or software
| problems. Some are downright silly. But that's largely true
| of software development, too.
| JohnWhigham wrote:
| _The best managers make you feel like there is no manager._
|
| Excellent summation. They're there to help you to do your job
| better.
| sonofhans wrote:
| > The best managers make you feel like there is no manager.
|
| Totally agree. This has been written before, many years ago.
| I'm sure it's possible to find references from other cultures
| and traditions as well:
|
| "When the Master governs, the people are hardly aware that he
| exists."
|
| http://thetaoteching.com/taoteching17.html
| dorfsmay wrote:
| I absolutely hate useless management layers and unnecessary
| ceremonies but I've been on teams with no hierarchy and it was
| Lord of the fly until the most power hungry developers became
| the effective lead/manager.
| watwut wrote:
| I was on such team too. There was cycle of power hungry
| leader, revolution, everyone for himself which special kind
| of dysfunction, someone else takes power again, revolution,
| everyone for himself which special kind of dysfunction, ... .
| alchemism wrote:
| I've been in the startup scenario where the most power-hungry
| developers successfully rebelled against the CTO and had him
| resign; "Lord of the Flies" is exactly how I described the
| maturity-vacuum period that followed.
| j4yav wrote:
| I have something like PTSD from a similar situation.
| vc8f6vVV wrote:
| Nature abhors a vacuum (c) We are social animals and there is
| no such thing as "all people are equal" or "flat
| organization". There is always a structure, only it can be
| explicit and regulated (and usually more efficient and easy
| to navigate due to explicit rules), or it can be implicit
| (aka Wild West).
| skeeter2020 wrote:
| My first questions would be (1) how big is/was the team? (2)
| how experienced? (3) how fast were you growing/changing? (4)
| without any sort of process or documentation how did you handle
| performance reviews (good and bad), promotions, growth? I'd
| also bet that your lead was (a) really good and (b) doing 2
| jobs.
|
| IME smaller organizations with experienced & stable teams can
| do fine without formal management, especially if the system is
| small enough to fit entirely in you head. Beyond that you need
| some form of management.
|
| Aside: you come off at best somewhat ignorant or less
| charitable as kind of a jerk; there's a lot more to running a
| software company than writing code by yourself. We get it; you
| think all managers are useless MBA suits, but some of us
| actually still self-identify as devs that just want to improve
| the systems that build software. You can only get so far
| focusing solely on individual improvement.
| mason55 wrote:
| Managers are not needed but management is. There are many ways
| to fulfill the task of management, one way is to have a
| manager, one way is to have the developers handle it
| themselves.
|
| If you're lucky you can get a team of devs who are capable of
| self-managing and communicating with the outside world and
| handling everything else they need to do to be successful
| besides just writing code (writing JDs, talking to customers,
| dealing with budget, etc.)
|
| But hiring a team like that is hard. Developers like that cost
| a lot of money. The law of comparative advantage is a real
| thing. If you can't hire a team that can manage everything
| themselves you can at least piece together people who can
| fulfill the different functions.
|
| And that's how you end up with developers and managers.
| morelisp wrote:
| My experience is about 1/3 of developers are completely lost
| without a manager checking up on them periodically, between 1-5
| times per week. (Varying depending on seniority, while the
| frequency changes it seems like the percentage does not; junior
| developers are more likely to get lost but not always in the
| ways a manager check-in helps.) By this I don't mean a one hour
| meeting, but something more like a standup, or just an email
| "hey, last week you were working on X and I didn't any updates
| about it, how's that going?"
|
| If you get a team of purely the of developers that don't need
| this, it's great! But that means somewhere else there's
| probably a team that's 2/3 or worse that, and that's hell. If
| there's a manager, it's luckily just hell for the manager.
| abcalphabet wrote:
| We're going through this at the moment, company got bought,
| original CTO & IT Director left. Now the new bobble-heads try
| and introduce nonsense processes, much to the dismay of
| everyone already working productively.
|
| I think the problem in large part is that most "managers" are
| brought in later on and then feel they have to go above and
| beyond to justify their existence/position/salary. In the end
| they do things just to be able to talk about all the amazing
| things they are doing and how their shiny new processes are
| helping everyone so much.
|
| I have yet to see a successful founder introduce nonsense
| simply for the sake of it.
| ngngngng wrote:
| There are some jobs with a goldilocks element. Such that the
| job can be done just right, but it is easy to overdo or
| underdo it. Management is the most common job in this
| scenario, and we tend to really notice when it is overdone.
| Toes get stepped on, trust is not felt, everyone is unhappy.
| Unfortunately it many of the people that get into management
| try and push themselves to achieve as much as possible, which
| is what leads them to overdo it and make their teams unhappy.
| abeppu wrote:
| > The lead developer handled communication with the IT Director
| about project status; and that wasn't very often.
|
| I think depending on the organizational context, and how much
| external communication a project needs to succeed, this can
| mean that the lead developer becomes a manager in
| responsibility but not in resources. This can harm the project
| and its participants both because the lead developer's
| attention may be siphoned off towards management-related
| activities, and because their advocate to upper-management is
| less equipped.
|
| E.g. Can the lead developer recognize that the project needs a
| person with a skillset not already present, write a JD and
| oversee the search for a suitable candidate? Or will the
| organization say "tech leads don't hire; managers hire"? Does
| the lead developer have the same access to the decision-making
| process of the larger org that a manager would, or will they be
| denied access to certain meetings, documents and resources?
| ("Sorry, we keep that personnel info in the same place we keep
| compensation info, which only managers should see").
|
| I think the article makes the point that the problems
| preventing an org from making good products or decisions
| extends all the way up to the CEO, and I agree. And in the many
| organizations, software managers are a necessary evil to try to
| compensate for those broader dysfunctions.
| carbonguy wrote:
| > this can mean that the lead developer becomes a manager in
| responsibility but not in resources.
|
| I think you've nailed it here - what's been described is a
| manager under another title, and one who will be hampered in
| that role in the exact ways you describe.
| andrekandre wrote:
| ive seen this happen alot... a lead dev is a manager without
| a title, and is not recognized or have any true authority,
| and they arent compensated for it either... its the worst of
| both worlds...
| Maascamp wrote:
| If you had no KPIs and no meetings how did you know what to
| work on and what the company needed? Osmosis?
| jpseawell wrote:
| I've only ever heard of managers "working on developer KPIs"
| and never seen them actually defined and distributed.
| jimbokun wrote:
| KPIs are generally set on a timeframe where they usually
| become meaningless by the end of that timeframe. For
| software, goals set for a year out are almost never going to
| be meaningful by the end of the year.
|
| Pick your flavor of Agile or whatever process your team can
| agree to, but I doubt the term "KPI" will ever come up when
| doing real life planning and work.
| borvo wrote:
| When I was younger I wondered what all these other people in
| the business did with their time. Surely it was all about the
| code and all these other corporate drones just needed to
| respect that. Then I guess I started moving over to the dark
| side and got a bit more empathy for the real jobs that other
| people have to do - so devs don't have to spend ALL their time
| talking to customers, paying the bills, handling the marketing
| etc. Strangely many of these people, even customers, were
| curious about likely dates for shipping the work. Turned out
| their jobs depended on it too. I recently interviewed an
| engineer working at a startup run by engineers. There is no
| management, which he thought he'd like. Instead they use
| commitment. After 18 months of very long hours and weekends
| guess why he wanted to move on? Organizing the work and the
| people is an art, lots of people get it wrong even when they
| try hard to get it right - but these articles? I hope my
| competition is reading them.
| codingdave wrote:
| Bad managers are actively harmful to a team. Great managers
| will make a team shine with productivity and satisfaction.
| You'll never accept a bad manager again once you work with a
| great one. Sadly, they are few and far between. And to truly be
| great, their managers all the way up to the CEO also need to be
| great. So a role under such a leadership team is rare. But they
| do exist. It is worth your time to seek them out.
| cortesoft wrote:
| Seems like it depends on how you define 'manager'. Your lead
| developer is what I would call a manager. In my experience,
| most managers have been team leads who set priorities for the
| group, help arbitrate technical decisions, advocates for more
| resources for their team, negotiates with other teams over who
| will do what work and take responsibility for which parts of
| the system, advocate for promotions for their team members, and
| deal with underperforming team members.
|
| I don't know how a large company could function without that
| role. If you have 200 developers working on 100 different
| projects.... who is deciding what to work on? Who is deciding
| how many people should work on what? Those people are managers.
| cloverich wrote:
| I like how Engineering Manager is defined in "The Managers
| Path" -- which is what you are describing. They shoud be
| someone who does an occassional bug fix to maintain a boots
| on the ground approach, but is spending 95% of their time on
| the items you listed. I think one issue w/ Managers is that
| we get manager's who should be at this technical level, but
| are instead so hands off (or fully non-technical) they can't
| even reason (or delegate) priorities when architecture or
| tech debt is involved. To be fair, I have worked with fully
| non technical managers who had a good understanding of how
| much time to allot towards architecture, refactoring, etc.
| But those are rare.
| js8 wrote:
| Although I am not completely sure I agree with the thesis, I
| think it's worth pointing out that one of the largest software
| projects in existence, Linux kernel, doesn't have software
| managers either.
|
| In any case, when I first read the headline, I thought, well,
| in a worker cooperative, the developers can fix the bad
| management. :-)
| toomanybeersies wrote:
| A significant amount of work on the Linux kernel is done by
| contributors who on the clock for Intel, Red Hat, etc., and
| I'm sure have software managers.
| js8 wrote:
| That could sorta make sense if these managers would
| actually talk to each other, but.. I think they are not.
| bigbillheck wrote:
| > I think it's worth pointing out that one of the largest
| software projects in existence, Linux kernel, doesn't have
| software managers either.
|
| Most linux contributors, as I understand it, are paid to do
| it by their employers, and get managed that way.
| npwr wrote:
| But the Linux kernel had Linus Torvalds who acted as a
| dictator. We can argue he did some kind of technical
| management there.
| valenterry wrote:
| Yeah - I think that's good insight. You need someone that
| has all power and resolves conflict if necessary. But even
| for something as big as the linux kernel, Linus did the
| dictator part _and_ continued coding, doing PR reviews etc.
|
| So how much management is really necessary?
| jimbokun wrote:
| How much time did he spend on coding as Linux got bigger?
|
| And you could argue PR reviews was how Linus performed
| his management function. Which could be an interesting
| way to organize technical management in proprietary
| software projects, too...
| js8 wrote:
| I think the original article is predicated on the notion of
| "management" as a role (specific person so designated), and
| not a skill, that can be taken up by any developer. If it
| was the latter then the whole argument would fall apart.
|
| Personally, I think managers are primarily intermediaries
| between capitalists and laborers. So they are needed under
| capitalist mode of production, where surplus value is
| extracted (according to Marx, at least), but they are
| probably superfluous under different modes of production,
| like that of open-source software.
| Taylor_OD wrote:
| This can only be true for teams built of mid level to senior
| engineers, right?
| nickpp wrote:
| Well, in my experience I'd say it depends. It depends on the
| developer. But it takes a good manager to understand if a
| developer needs management or not... :)
| okprod wrote:
| _I 've come to the conclusion that software managers are not
| needed_
|
| I think some layer of management is needed for strategy,
| business operations, market positioning, etc., but they should
| get out of the way as much as possible, similar to how Joel has
| done it at Fog Creek.
|
| Many years ago I was visiting a startup being incubated at
| Stevens Institute in Hoboken, and there was a group of graduate
| engineer students on-site looking at a demonstration; the CEO
| asked what the most important factor in building the product
| was, and the very smart engineers talked about output,
| efficiency, portability/miniaturization, etc. The CEO stopped
| the brainstorming and said "whether or not someone will buy the
| product".
| AtlasBarfed wrote:
| Depends on the team experience, morale, complexity of product,
| organization, and customers.
|
| I also agree that a high-performing team tasked with a clear
| mission don't need more than a glorified secretary.
|
| But if any of those start to fail then it starts degrading
| everything. Without decent managers, development/progress can
| collapse.
|
| Decent managers can paper over the other deficiencies to a
| surprising degree.
|
| Good software devs can also paper over deficiencies in the
| chain as well to a surprising degree.
|
| Bad managers can be part of the problem too. Bad devs will
| obviously kill the whole thing.
|
| And of course everyone in that chain has their own agendas,
| from selflessly devoted to the macro-organic corporation to
| machiavellis edging for any economic and power advantage.
|
| Capitalism is supposedly about the free market, but
| organizations strangely don't align themselves to the basics of
| microeconomics. They are centrally planned top-down pyramids.
| Incentives will never properly align to maximize organizational
| productivity because of the totalitarian nature will reward
| those with power, not productivity.
| fghfghfghfghfgh wrote:
| After 17 years of development and 8 years of management I've
| come to the conclusion that developers are delusional about the
| relative importance of their role. I shall be the first to
| admit that - I used to be one myself.
|
| Your run of the mile non-technical manager sure is not very
| good at understanding the intricate complexity of all the
| moving parts of creating software.
|
| Developers on the other hand appears blind to the fact that
| they play only a minor role in the bigger picture. While
| technology is difficult it pales in comparison to orchestrating
| people across sales, strategy, business transformation,
| creative, development, QA, operations and infrastructure.
|
| That's just the horizontal alignment. In a single entity. In a
| single timezone. With a single vendor. A scenario which never
| happens because in real life you have at least 3 levels of
| technical management, multiple divisions/departments involved,
| spread across continents and multiple vendors participating.
|
| You need competent people to align, coordinate, communicate and
| pick up the stuff which falls through the cracks. Developers
| are not good at this work.
|
| You need a manager. And of course they must be competent.
|
| EDIT: I don't actually think developers are delusional. I
| worded the phrase to mirror the absolutism of the statement
| "I've come to the conclusion that software managers are not
| needed" which is just plain silly.
| dominotw wrote:
| > developers are delusional
|
| > Developers .. appears blind to the fact that they play only
| a minor role in the bigger picture.
|
| > Developers are not good at this work.
|
| Developers aren't some special creatures with one dimensional
| fixed mindset. They can do whatever that needs to be done.
|
| This is kind of silly stereotyping precisely why makes
| developers hate managers. I hate managers who think of their
| team as mere code monkeys that are "not good at" some
| mythical management work.
|
| I am a manager myself but I never diminish role of my team
| members as "minor players", "not good at work" ect. They are
| my peers and partners who are equally as "major players" as
| anyone else.
| fghfghfghfghfgh wrote:
| My reply was worded to mirror "...I've come to the
| conclusion that software managers are not needed." which is
| obviously nonsense.
|
| "Developers aren't some special creatures with one
| dimensional fixed mindset. They can do whatever that needs
| to be done."
|
| Yes, but it is ok to generalize in a broad discussion like
| this one. Otherwise we can have no meaningful conversation.
| In general managers do not understand developers. And in
| general developers do not understand management. Those that
| are good have been exposed to both sides.
|
| I never diminish anyone but it is naive to think that
| everyone contributes equally.
| jpseawell wrote:
| I definitely agree that _(in general)_ devs and mgmt do
| not understand one another.
|
| I think this is bc one practices abstraction while the
| other practices persuasion.
|
| I see these two forces as equal and opposite. A yin and
| yang kind of thing.
|
| It appears that the best orgs have these two things in
| balance.
| warkdarrior wrote:
| How are abstraction and persuasion "equal and opposite"?
| They seem to be completely orthogonal activities.
| billytetrud wrote:
| Don't mirror someone's words if you don't mean it. You're
| just being a disingenuous ass by doing that.
| e_d_e_v wrote:
| > which is obviously nonsense.
|
| I think I've observed enough of this sentiment over the
| years, from some very smart and successful people, to
| come to the conclusion that, if it is nonsense, it is
| non-obvious.
|
| > I never diminish anyone
|
| Perhaps you never _intend_ to diminish anyone, but to
| some, your statements may reasonably appear to be
| diminishing some cohort.
| camgunz wrote:
| > They are my peers and partners who are equally as "major
| players" as anyone else.
|
| I love this. The best teams I've been a part of are those
| that had a mutual respect for everyone else's work. I was
| an engineer on those teams, and thank god for the product
| manager, tech lead, design work, ux researchers, etc.
| Things work so much better when there's a real culture of
| "we're all in this together, and we all have important
| roles to play".
| wiz21c wrote:
| but in the end, you decide who gets promoted or not, you
| decide who has to put the "extra effort" to satisfy whoever
| you work for. So of course everyone is a major player, it's
| your best interest.
|
| but you're also the one who gets the time to see the big
| picture and hopefully realize that, yes, the development
| side of a project, while the most fundamental, is also just
| one of the part. The other being : handling customer
| expectations, making sure the budget use can be explained,
| making sure people stay happy even when confronted to
| "absurd" customer's request, making sure to understand the
| project ecosystem to make sure you get the right customer
| contact person in front of your team, making sure the one
| dev with a broken back gets a proper chair, making sure
| good project are rewarded, you make sure HR's department
| craziness don't alienate your devs, you-f*g-name-it (been
| there, done that, got the tshirt : I've been in dev,
| business consulting and management :-))
| ABCLAW wrote:
| >the development side of a project, while the most
| fundamental
|
| There's an entire world of industries in which software
| is a 'nice-to-have' enabler of various levels of business
| logic, not the product itself.
|
| The assumption that development is the fundamental key to
| all projects is, I'd imagine, the 'delusion' referenced
| earlier.
| wiz21c wrote:
| Yeah, I work in an industry where software _enables_
| things, so it is central. But even in my industry
| (business apps), we could just go on with pen and paper
| like before. So programs are not "absolutely
| fundamental" but in the 21th century, well, they are :-)
|
| But I can admit it's not like that everywhere, sure. But
| I've yet to see industries where people pay programmers
| to work on IT project which are not fundamental in a way
| or another or in the process of becoming fundamental. The
| point is when programs get deployed, they usually
| transform (and hopefully improve) a situation. Once the
| transformation is accomplished, the program becomes
| fundamental...
| vc8f6vVV wrote:
| You understand, that company goal is not to "build a good
| product", even less to "write a good code", it's to
| increase a company value (in the sense that "good code" is
| orthogonal to the goal)? It might be unfortunate for
| developers, but quite often (almost always from what I've
| seen) developers' role _is_ minor here. Not in derogatory
| sense, just money don't come from writing code, they come
| from sales. Also no, not everybody can be a good manager,
| and not everybody can be a good developer, as those two
| roles require different mindsets and different training, so
| very few people can effectively do either (and not at the
| same time). So a good developer normally can't do "whatever
| needs to be done". You don't want a developer to do your
| surgery, do you?
| sporedro wrote:
| I agree, you need a manager, but through my limited
| experience I feel as though the issue is developers are
| mostly detached from the buisness end of things. When things
| go wrong or some issue occurs I've always had managers step
| in to aid from the buisness side. You almost need a manager
| who has developer experience like yourself to make for a good
| manager. I suppose even a manager who is able to understand
| the general overview of what the developers are doing would
| be good.
|
| Basically it seems the average manager in buisness would be a
| bad fit to manage developers. overall a manager is still
| needed for sure. I guess its the same everywhere though a bad
| manager vs a good manager makes a world of difference.
| meowface wrote:
| Clearly some management is required somewhere in the chain,
| and if they're any good then they're important. But certain
| tiers of management seem to largely be pointless
| intermediaries; especially if they're not as technical as the
| developers.
|
| I've stopped being skeptical of the general concept of
| management. I'm no fan of LinkedIn, but Reed Hoffman said
| something in a talk that instantly changed my entire opinion
| about the idea of a developer moving up in the hierarchy and
| no longer writing code. Paraphrased from memory: "You're
| still programming; just at a higher level of abstraction."
| sadfasf122 wrote:
| lol. try an A/B test.
|
| A) Get rid of developers B) Get rid of dev managers
|
| Let me know :)
| dnndev wrote:
| As a CEO and long time developer before then... its
| complicated. High performance teams are killed by managers
| unless they stay out of the way and then whats the point
| right? Managers are great for managing clients, but not devs.
|
| Low performance, bare minimum devs, sure need reminding and
| pro-ding to get anything done... yes, you need managers to
| babysit.
|
| Companies with heavy management usually have mediocre at best
| devs and little to no innovation. They have great sales and
| support - this keeps them alive.
|
| Captain obvious here - there is no one size fits all. Do what
| makes sense at your org and take home a paycheck or leave and
| start your own business - there has never been a better time!
| skeeter2020 wrote:
| just an observation: if you moved from developer to CEO
| without significant time as a Dev or Eng manager you have
| very different skills and focus. CEOs of all but the
| smallest companies are playing checkers; Dev Managers play
| chess. This isn't some sort of insult; we need to focus on
| individuals with distinct skill sets and characteristics.
| CEOs can't and shouldn't be concerned with this level of
| detail.
|
| It's also uncharitable to split teams into either high-
| performance special ops teams vs. mediocre, low skill / low
| potential teams. Two trends make this distinction
| meaningless: GROWTH and SCALE. If these don't apply then
| you can totally let the team self-manage. FANG companies
| typically have all those rockstars you're looking for and
| multiple levels of technical management.
| lostcolony wrote:
| Google even tried to go without managers. They
| backpedaled pretty quickly. https://www.inc.com/scott-
| mautz/google-tried-to-prove-manage...
| pc86 wrote:
| Even if CEOs "can't and shouldn't be concerned with
| [individuals with distinct skill sets and characters]"
| (not a point I'm conceding, what makes you think a CEO's
| job is "checkers" compared to the chess of a Dev Manager
| who is realistically 2-4 levels below them in the
| organization?
| lostcolony wrote:
| 'High performance teams are killed by managers unless they
| stay out of the way and then whats the point right'
|
| The point is two-fold. First, creation and maintenance of a
| high performance team as the company grows is worth someone
| focusing on, not just hoping it happens organically
| (sometimes people, especially new hires, need to know "yes.
| You are really free to make this decision yourself. I'll
| back you on it." Likewise, sometimes people doing good work
| need someone who can spend the time to highlight the value
| of it to the rest of the business, to effect a promotion).
| Second, ensuring other needs of the business inform that
| high performance team, WITHOUT interrupting it, are also
| worth focusing on.
|
| These are both true regardless of the environment, but
| become bigger needs the larger the company is.
| dnndev wrote:
| "creation and maintenance of a high performance team"
|
| Managers do this? right, right. I would say managers at
| best dont mess it up. Creation and maintenance of high
| performance team comes from within. The surrounding
| support certainly helps, but to say a manager creates and
| maintains this is a bit of a stretch.
|
| "ensuring other needs of the business inform that high
| performance team"
|
| I have found if it needs to be known or communicated it
| will happen. High performance teams are not just coders
| (another fail from managers) they are intelligent people
| who can read and write emails and know how to speak to
| other humans. This may be the stereotype of some hot
| pocket eating teenager in a closet from the movies but
| that is certainly not the case in most professional
| environments.
| lostcolony wrote:
| So for the first, I am explicitly describing managers in
| an agile, team lead style. But, yes. Managers, first and
| foremost, hire the team. Ideally from feedback, but
| ultimately the manager is responsible for the team's
| formation. But then the manager also has to help smooth
| out bumps along the way. Having someone objective who can
| help smooth out disagreements can be HUGE. Likewise
| someone who can give feedback to individuals; a large
| personality can be a huge asset to the team, but can also
| leave others feeling alienated; someone who can help
| carve out space for those others to speak up, and to help
| coach the person filling the room how to recognize that
| and also to carve out space for others, is immensely
| helpful. And maintenance includes progression, both for
| individuals and the team; devs are often focused on what
| they're working on, they're not evaluating how to get
| their work recognized, and more junior ones often aren't
| evaluating how to grow themselves. It also includes HR
| issues; having someone who can do the legwork for your
| Visa sponsorship, for instance, frees you to do real
| work. A good manager is basically the team's admin
| assistant as well.
|
| For the second, of course they are. You have to take the
| two statements I made together. There is a spectrum; at
| one end are devs working on what they feel is important,
| but not knowing they're not working on what the business
| feels is important. At the other is the business deciding
| everything the devs do, oftentimes changing priorities
| every week. Having one person as a middleman there can be
| immensely helpful. That may look like a manager saying
| "Hey Bob. Jane has this need; work with her to understand
| and implement it", and handling everything off to a dev,
| but the point is that the manager, A. Gave Jane (and
| everyone else) one person to reach out to initially when
| it came to their needs of the team, B. Helped determine
| that Jane's need was a priority against all the other
| needs, and C. Gave Bob permission to ignore all other
| incoming requests and direct them back to the manager, to
| focus on Jane's need. That is not to say Bob is not
| reading and writing; it IS to say that Bob can benefit
| from someone keeping him from being interrupted by every
| person in the business with a need who thinks he might
| help.
| TimPC wrote:
| High performance teams are usually created by good
| management. If you change the management then bad
| management can easily undo that. My best managers have been
| deeply technical people with good people skills, an
| interest in management, and willingness to get out of the
| way and no longer make the decisions they made when they
| were a developer. Management is a lot more than babysitting
| it generally involves a lot of coordination up and down the
| organization to ensure the team is doing the right work in
| terms of organizational and customer priorities. Good
| management can give you what to work on while leaving you
| to decide the how.
| oneshoe wrote:
| This feels right. I also believe that what people need are
| LEADERS and not MANAGERS. I'm sure there are plenty of
| examples of the two on the web.
|
| The challenge I see a lot of managers have is that they
| look to much at an engineer as a widget and not literal
| human that is just as capable as the manager (most the
| time). There are often times no lines between roles and
| responsibilities and every shop does that slightly
| different, and not based on some framework they masterly
| put together, but just something based on how the pieces
| fell in place with some help from previous experiences.
|
| I just wanted to say also - _most_ engineering managers are
| not good managers. They were good engineers that are in the
| unfortunate process of the Peter Principle.
| jollybean wrote:
| 'High Performance Devs' I've found tend to build the things
| they want to build.
|
| I've yet to meet the kind of superstar dev who is also
| superstar market and customer oriented.
|
| That can be challenging as a lot of important innovation
| doesn't come from customer feedback and you need talented
| people to do those things as well.
| dnndev wrote:
| This is very true. Most shops have an R&D team for long
| term innovation and other devs like myself who love
| customer feedback and want to deliver solutions now.
| hallway_monitor wrote:
| I have not heard this about "most shops", in fact I have
| never worked in an org with a functioning software R&D
| team (unless you count enterprise architects choosing
| vendors).
| Karrot_Kream wrote:
| No but I've seen similar dynamics play out at most
| companies. Broadly, "product teams" focus on customer
| feedback and delivering value to customers, at the
| expense of technical debt and lots of fickle requests.
| "Infrastructure" teams are heavily insulated from
| customers and deal with a more long-term roadmap and
| fewer changing requirements.
| gregors wrote:
| Product and Engineering need to be peers in this regard.
|
| I think Spolsky said it best about the dynamic between
| managers, product and developers
|
| https://youtu.be/A3-ijSmDQ3c?t=983
| dnautics wrote:
| oh, and any given dev can switch from high performance to
| bare minimum depending on the project, week of the month,
| what they ate for dinner last night, etc.
| dnndev wrote:
| Same could be said for a manager.. or a manager that gets
| bad devs or devs that get a bad manager. This is the
| value of a hands-on ceo that does not have their head in
| the sand.
| oxfordmale wrote:
| The role of the manager is to ensure the team can get on
| with their jobs, to celebrate their success and have their
| back when things don't go according to plan. Unfortunately
| most manager can't help to start interfering with the team
| and go for a top down driven management style.
| captainmuon wrote:
| I guess the problem are not managers per se, but non-
| technical managers. Somehow it is OK to have a pure
| salesperson / MBA manage engineers, but you would never put a
| developer in charge of the sales department.
|
| I think many developers (not just coders, but in general
| technical people who make the actual product, designers,
| engineers, ...) feel there is an unfair primacy of managers /
| business people over developers / technical people. This is
| even reflected in the job descriptions: I hate the term
| "individual contributor" for example, it implies
| replacability and that non-ICs (managers) contribute more
| than one person.
|
| Not every company has "bullshit" managers and for sure some
| developers are delusional. But these bullshit managers exist,
| and I believe this happens when you put people who are far
| away from making the product in charge. If the managers and
| executives are not intimately familiar with the product and
| the customers, then the product becomes some interchangable
| thing that you hustle. This can be disastrous for the work
| climate but also for the success of the company.
| Pokepokalypse wrote:
| So much this.
|
| I even worked at one incredibly toxic organization for a
| year, before I left, where sales people would literally
| roam the office, grab a dev, and task them with a customer
| request.
|
| This company was in a very specialized niche market, and
| was basically the only player. The only thing I couldn't
| figure out is why someone else hadn't come along and eaten
| their lunch, because they were suffering from chronic
| under-funding. Getting them to commit to migrating to AWS
| was a major eye opener for them; since they suddenly had to
| actually pay bills or they'd lose the whole operation.
| dv_dt wrote:
| I always wondered if it was possible to build an inverted
| company organization, where developers/engineers were
| formally at the head of things, and much of the
| administrative tasks that management works on were subbed
| to specialists reporting to the developers.
|
| If you look at a lot of pretty incredible projects that
| often were finished ahead of schedule or with
| groundbreaking capability, they often happen to be led by a
| deeply technical person. e.g. Hoover Dam, the SR-71, etc.
|
| If you look at CEOs of tech companies, I believe a majority
| of them have an engineering undergrad degree of some form.
| ruste wrote:
| I work at a company that operates much like this. I've
| passed up on more lucrative opportunities in the past
| because it's such a great place to work as a developer as
| a result.
| dv_dt wrote:
| Do you think the company holds it's own in terms of
| competitiveness vs other companies as well as making a
| reasonable profit to survive?
| lostcolony wrote:
| Actually, it implies that managers are multiplicative. You
| -hope- that it's a value > 1.0. I quite like the term
| individual contributor - it implies you're actually doing
| work (and that it falls on the rest of the business to make
| sure you know what work will be valuable).
|
| But, yes. Bullshit managers invariably choose to take
| empowerment onto themselves, despite a lack of knowledge,
| and oftentimes without any real responsibility, either
| (i.e., they don't bear the consequences of their
| decisions).
| jollybean wrote:
| I generally support this assessment.
|
| As a 'developer' I thought 'we were doing all the stuff'
| while everyone else catered to us.
|
| During my roles out of that seat, I view 90% of development
| as a form of intellectual labour, it's just work, one piece
| of many things.
|
| The hardest job by far is selling.
|
| The next hardest job overall, as the commenter mentions, is
| making a 'whole product' and targeting it at customers.
|
| Engineering is hard, but not harder than the above.
|
| I would almost like every Engineer to work for 3 months in PM
| or Sales just to get their perspective flipped.
|
| Engineering feels more 'worky' because it's more direct.
| gregors wrote:
| Regarding selling - I've know amazing people who could sell
| all kinds of products that don't even exist. So selling by
| itself doesn't seem to be the hardest thing - selling
| something that relates to the reality of the product is far
| more difficult.
| mirsadm wrote:
| It sounds like you've gone from one extreme to another. None
| of the things you mention pale in comparison to software
| engineering at all. They are all solvable problems that many
| people can do. Sometime they are difficult, often they are
| not. Managers are certainly not useless and do work for
| certain types of organizations. They are not always needed
| though. Believe it or not there are people capable of
| managing and programming at the same time. You seem to be one
| of them so your view point is very strange.
| fghfghfghfghfgh wrote:
| No, I've actually mostly worked in well balanced places. It
| is my experience that technology is the lesser issue and
| the one with the smallest impact. That's not to diminish
| the highly skilled developers - the work just have less
| impact that we seem to believe.
|
| I do not believe in self organizing teams. I have not seem
| them work. Without direction the team will fumble until
| someone assumes control. I have also not seen many happy in
| such an environment.
|
| The opposite is strict top-down control, such as what is
| often described and lamented on HN, is equally bad. No one
| wants to work under a dictator.
|
| There's a balance to be struck between authority and
| autonomy.
| Mauricebranagh wrote:
| Inexperienced developers can be delusional especially if they
| see their role as 100% banging out JIRA tickets
| alexvoda wrote:
| Your claim is provably false.
|
| Large scale software development without management is proven
| to be possible by the existence of functioning FLOSS projects
| like the Linux kernel, various GNU tools, KDE and plenty of
| other examples.
|
| I have not heard of a single software development company
| with 0 software developers. Not even Oracle manages that.
|
| Managers are necessary for the parts of the company other
| than development. You can have a FLOSS project developed
| organically, and separately a company in the business of
| support, services, etc. Managers are also necessary in order
| for the company to exercise control over the development and
| extract value. And this may be needed for a company to
| survive. But they are not needed for software development
| itself.
| vc8f6vVV wrote:
| Even FLOSS enthusiasts need to eat. Money don't come from
| writing code by itself, they come from sales. Or from
| donations. In both cases there is a lot of non-coding work.
| Do you want to do it? I don't. How do we call those guys
| who organize donations or sales? Collect requirements? Yes,
| there are requirements in FLOSS too, otherwise you wouldn't
| get donations, or support contracts, and those requirements
| are coming from the people who pay. Let's call everybody
| developers, only some won't write code and would organize
| coders, gather requirements, distribute payments. Wait,
| those people are currently called managers.
| granshaw wrote:
| This is all true, but reads more like a PM-type role, which
| is absolutely critical.
|
| I understood GP's point as more directed towards "pure Eng.
| manager" type positions, often when there's also already a PM
| present. And I've witnessed first hand how his criticism
| rings true in that case.
| swader999 wrote:
| Yeah technical pm or a pm that understands the business
| deeply are critical.
| jimbokun wrote:
| > Your run of the mile non-technical manager sure is not very
| good at understanding the intricate complexity of all the
| moving parts of creating software.
|
| > Developers on the other hand appears blind to the fact that
| they play only a minor role in the bigger picture.
|
| Y Combinator was largely founded as a rejection of this
| premise. Paul Graham believed it was much easier to teach
| great Software Hackers how to business, than it was to teach
| business folks how to software. I think it turned out pretty
| well.
|
| > A scenario which never happens because in real life you
| have at least 3 levels of technical management, multiple
| divisions/departments involved, spread across continents and
| multiple vendors participating.
|
| And your organization with 3 levels of technical management
| and all those divisions and departments will often get their
| lunch eaten by a very small group of people working in a
| startup, moving faster and accomplishing more in less time.
| fghfghfghfghfgh wrote:
| "Paul Graham believed it was much easier to teach great
| Software Hackers how to business..."
|
| I agree
|
| "And your organization with 3 levels of technical
| management and all those divisions and departments will
| often get their lunch eaten by a very small group of people
| working in a startup, moving faster and accomplishing more
| in less time."
|
| You misunderstand. It is not my org - it is the client
| orgs. And none of those are software companies. The speed
| with which you can move is irrelevant because you are
| constrained by the pace of the org you're working for.
| swader999 wrote:
| This is true but I've also seen developers add ten percent
| more revenue to an organization on a rewrite of an existing
| billing system and it wasn't due to any insights from
| management. It was many conversations with key business users
| and developers. Management knew enough to step back and
| loosen the reigns. Everyone can make a huge difference on a
| project, and a team of non hero's that just care about
| learning the business and the craft can deliver greatness.
| ixs wrote:
| This! So much.
|
| Sometimes you can plan for success/heroic actions (in the
| good way) but often it happens by accident.
|
| The right person digging into a weird problem they
| encountered, two people sitting together to review a design
| or someone doing a firmware update that fixes a bug in the
| RAID controller giving you double the IOps...
|
| I have tons of anecdotes from colleagues who did some
| unplanned work just because they talked with someone else
| and that work then turned out to have massive positive
| impact. The results are lauded but it wasn't even clear
| when the "little" project started that it would actually be
| a massive boon.
|
| At a prior job (some website selling hotels online) I was
| responsible for the project that ended up giving the whole
| fleet a 25% capacity boost. Instead of 2000 machines we
| only bought 1500 next quarter. If we calculate that in
| perpetuity my project was a massive success. Millions of
| EUR saved since 2011.
|
| The project initially started out as "tons of people tried
| building a decent perl RPM but couldn't get it to work,
| could you have a look?". The guy originally tasked with it
| was busy fixing a broken LDAP server. So I built some RPMs,
| wrote a bit of tooling around it and we ended up with a
| Perl environment separate from the system perl which was
| great because the business was nearly exclusively running
| on Perl 5.8.9. At that point I looked into using that to
| get us off CentOS4. With the help of two colleagues we got
| a CentOS5 environment running and could migrate to a x86_64
| environment.
|
| That migration than gave us a 25% capacity boost and
| happiness ensued all around. The OS upgrade wasn't part of
| the original project scope, we just went with it because it
| made sense and management understood that it's a good idea.
| mumblemumble wrote:
| I'd like to make a wild inference and suggest that you and
| the parent poster are talking straight past each other,
| because you're drawing your experience from two different
| business paradigms.
|
| kbmunchkin wrote:
|
| > The lead developer handled communication with the IT
| Director about project status
|
| The fact that the ultimate person being reported to was the
| head of IT strongly implies to me that it was an in-house
| development team working on in-house projects.
|
| Your list,
|
| > orchestrating people across sales, strategy, business
| transformation, creative, development, QA, operations and
| infrastructure.
|
| Strongly implies that your experience comes from building
| consumer products.
|
| Personally, I've spent time working on both successful and
| unsuccessful projects on both sides of the fence. What I've
| seen is that the most straightforward way to create a
| dysfunctional team is to try to take what works from one
| context, and apply it uncritically to the other. I personally
| hate working with a dedicated product manager on an in-house
| project every bit as much as I hate working without a
| dedicated product manager on consumer-facing stuff.
| fghfghfghfghfgh wrote:
| Nah, we're not talking past each other but we likely come
| from wildly different backgrounds.
|
| To make a general statement saying managers are not needed
| is as silly as saying all developers are delusional
| TchoBeer wrote:
| Consider that those two statements may be about in the
| same wheelhouse, but "developers aren't needed" is way,
| way more rediculous than "managers aren't needed".
| joshuamorton wrote:
| > but "developers aren't needed"
|
| No one ever said this though, I'm not sure what the point
| of bringing it up is.
| [deleted]
| supergeek133 wrote:
| This is a similar mentality of people who get very upset over
| incentives sales gets and/or "company provided trips".
|
| We all forget, at least in a for profit company, that we are
| all employed by selling things. Like it or not without the
| good salespeople, some of us don't have jobs.
| ferdowsi wrote:
| Strongly agree with this. I've been in situations where my
| team had no manager, a bad manager, and a great manager. The
| situation where I had no manager was the worst, by far.
|
| I've found that if you throw a bunch of Alpha Geeks together
| without constraints you may as well be herding cats. They'll
| want to work on their individual wishlists of strategic
| research problems (throw in this new tool! new methodologies
| I saw at this conference!) with less concern for the
| unromantic tactics, socialization, and alignment that makes a
| project succeed.
| myWindoonn wrote:
| A delusion is a sincerely-held false belief. Please consider:
| If all of the developers left your organization, could it
| still produce products? How about if all of the managers
| left? Your implicit devaluation of labor is not congruent
| with the actual reality of whose hands work the keyboard.
|
| (And before you write a knee-jerk response, double-check your
| reasoning. Without managers, developers produced the Free
| Software ecosystem. Without developers, what did managers
| produce?)
| vc8f6vVV wrote:
| Ask yourself who paid for the Free Software first. We are
| all humans and need to eat.
| meh99 wrote:
| Anecdotally I've seen the same in managers.
|
| I tend to believe these arguments just curve right into
| confirmation bias.
|
| I've been on teams that worked fine with managers and those
| that did not. It depends on the commitment of the actors in
| question.
|
| Anything else is reading what we want to in the tea leaves.
|
| Edit: Been working on distributed systems since the late 90s,
| from public uni to big corp, to day 1 startups. It's just
| computer configuration. Not magic.
| OhNoMyqueen wrote:
| The issue with this argument is that a significant part of
| the "bigger picture" is artificial bloat which emerges from
| the fact of having layers of management. Managers spend much
| time actually managing themselves. It's of course not all
| black or white.
| fghfghfghfghfgh wrote:
| I don't think it's an issue with my argument but I do think
| the difficulty of grasping the bigger picture is a major
| issue.
|
| It can be reluctance to understand why you're doing what
| you're doing. It can also be because no one cares to
| explain it to you. Most of the time it's probably between
| those two extremes.
|
| And yes some times it's bloat. But rarely all of it. I
| don't have a solution to this.
| dgb23 wrote:
| This reads almost like a tautology.
|
| I'm reading: "You need a manager to coordinate a deeply
| hierarchical and separated structure with production at the
| bottom and the clients at the outside."
|
| I mean no disrespect, but from my perspective I see a deeper
| problem here that is being patched over by exceptional people
| like yourself. Shouldn't the creators and clients have a
| major, high impact role and the coordinators a supporting
| role in terms of decision making?
|
| To make an exaggerated joke it looks a bit like a dictator
| complaining about all their responsibilities and the hard
| decisions they have to make. Well maybe they shouldn't even
| be in that position to begin with.
|
| And yes I've seen the diagrams and the theory behind this.
| But I've become more and more suspicious of bureaucracy and
| process that tries to fight the symptoms of lack of trust and
| human connection.
| geggam wrote:
| >And yes I've seen the diagrams and the theory behind this.
| But I've become more and more suspicious of bureaucracy and
| process that tries to fight the symptoms of lack of trust
| and human connection.
|
| This resonates but what I have seen is when you engage a
| company that has this model you have to emulate their model
| to fit within their needs, then you get infected with it.
| fghfghfghfghfgh wrote:
| Ha - yes, you're right it sounds like a tautology. I worded
| my answer to reflect the absolute statement of no manager
| is ever needed.
|
| "Shouldn't the creators and clients have a major, high
| impact role and the coordinators a supporting role in terms
| of decision making?"
|
| No. The creators usually answer "how to do it". The more
| important question is "what to do". Both groups are
| important but doing the right thing is more important than
| how you do it.
| tarsinge wrote:
| > developers are delusional about the relative importance of
| their role
|
| I think it's that developers fail to grasp that they are in
| the enterprise world. Web development and SaaS has blurred
| the lines, but at its core it's the same: the product you
| work on is a tool for another business. It's a bit more sexy
| because it's not mainframes, cubicles and suites anymore, but
| in the end the job is the same. And in that setting, the role
| of a developer is indeed minor in the bigger picture. There
| are exceptions in R&D, cutting edge projects, or in an early
| stage startup, but for the vast majority of developers the
| above is true.
| waheoo wrote:
| I think you're both right.
|
| Management is 100% required.
|
| What the ap is missing is that good management is almost
| invisible to the IC and only shows up when you need them.
| kosma wrote:
| Then make sure developers are deeply aware of all the
| concerns you listed. A large part of why developers think
| they are the center of the world is because they are
| meticulously isolated from said world. This is exactly what
| the article addresses as one of the main concerns.
| jpseawell wrote:
| As a developer, I've noticed a pattern: devs complain about
| too many meetings -> devs are left alone (aka isolated) ->
| devs complain about being left out of decision making
| process/chain of comm.
| terrib1e wrote:
| I agree. And then if the same devs have reduced meetings,
| are included in more cross dept initiatives, and included
| in decision making, they end up upset that their freedom
| is suddenly gone. Its not even just devs this is a common
| thing from call center reps to the top of the broken
| pyramid. Everyone is the linchpin in their perceived
| contribution to the world.
| strken wrote:
| Meetings are to align people. Complaining about too many
| of them can be a sign of many different things, but one
| of the biggest is _needing_ to align with so many people
| to get anything done.
|
| If you hold the same number of meetings but stop inviting
| some stakeholders, those stakeholders are going to be
| upset. If instead you remove some meetings from the
| process entirely, by e.g. not requiring multiple design
| reviews for internal products, or by not letting platform
| teams force everyone else to use their software, or by
| letting teams spin up their own low capacity services
| without meeting with ops, or anything else that lowers
| the complexity of getting work done, then your team will
| be happy and the previous gatekeepers will be
| complaining.
| cloverich wrote:
| It's a good observation. IME you can't be in all the
| meetings you need to be in to obtain alignment on complex
| problems in a changing environment AND be effective in
| writing code, very generally speaking. My most
| frustrating career points have been when I was a tech
| lead, doing a bit of both. Being more purely IC or purely
| managerial, it is much easier to get important work done.
|
| Its also a grass is geener issue. Work is generally more
| enjoyable as an IC, you get to focus and write code.
| Until you end up having to build something really stupid,
| and you want more control over product direction. Then
| you end up as manager, and long for the simplicity of
| being able to focus and write code. At least that's how
| I've felt at times.
| smolder wrote:
| Both of those problems can be solved to a degree with
| more efficient communication. Async communication
| channels like email and other messaging are great at not
| wasting peoples time while keeping everyone in the loop
| who needs to be, properly used. Sometimes I think phpbb
| style forums would work better than the usual tools. But
| overall I find people don't experiment enough or put
| enough effort into optimizing communication and it leads
| to this false dichotomy of either isolation or time
| wasting. There's a middle ground of optional
| participation where you communicate widely but don't
| force peoples attention, and that's how you can reduce
| meetings without reducing valuable communication. You can
| always put a time limit on feedback if needed, mark some
| things important... Just find what works!
| fghfghfghfghfgh wrote:
| My answer was intentionally phrased to mirror the
| absolutism of the GP. A large part of my time is spent
| explaining why certain process is in place or why we cannot
| get a license for this or that tool or why one needs to be
| considerate of the other crafts.
| routerl wrote:
| The comment you replied to gestures at but doesn't outright
| say this, but I think you have a good point.
|
| I genuinely think that many engineering managers see their
| most important skill as "getting engineers to do things for
| reasons they don't understand".
| sidlls wrote:
| That isolation is often as much self-imposed as not. While
| the GP may have been a bit aggressive in his/her
| characterization of it, I agree with the general thrust
| that developers tend to be both narrowly focused on their
| own technical work and prone to inflation of its worth.
| KSteffensen wrote:
| > prone to inflation of its worth
|
| This issue is not limited to developers.
| sidlls wrote:
| Of course it isn't: most individuals tend to inflate
| their contributions' importance. There are matters of
| degree, though. My experience is that developers tend to
| overestimate more often and by larger amounts.
| mucholove wrote:
| Why dont you see the lead developer as a manager in this
| instance?
| marcinzm wrote:
| Now imagine that setup with a bad tech lead who didn't know
| what they were doing. No oversight, no control, no feedback, no
| communicated goals to keep people accountable, etc.
|
| Every single approach works when you have driven, intelligent
| people who all mean to do the right thing. The validity of an
| approach is only tested when those things stop being true and
| you need to notice and recover.
| ketzu wrote:
| > who all mean to do the right thing
|
| And to some degree agree on what the right thing is.
| marcosdumay wrote:
| Well, no approach works when you have incompetent people
| doing the bare minimum and trying to subvert anything for
| their gain, so I don't known where you want to test anything.
|
| The truth is that not all approaches work on your perfect
| scenario. Many are known exactly for turning competent
| cooperative people into incompetent individualists.
| jimbokun wrote:
| But in reality most teams are somewhere in between?
| roland35 wrote:
| Aren't there a lot of things that need to get done that are
| annoying to developers? I personally enjoy having someone else
| in charge of all the manager responsibilities such as planning
| who works on what wand when, handling expenses, etc
| nine_zeros wrote:
| > After 12 years of software development, I've come to the
| conclusion that software managers are not needed.
|
| +1
|
| If devs are doing:
|
| - Scoping
|
| - Product design
|
| - Coding
|
| - Debugging
|
| - Scaling
|
| - Releasing
|
| - On call duties
|
| - A/B tests
|
| - Can't cause outages
|
| - Postmortems
|
| - Enhancements
|
| - Fight bullshit corporate politics
|
| - Fight to remove blockers
|
| - Fight to remove deadlocks
|
| - Ultimately produce something that earns money for the company
|
| - Write bullshit promotion docs for themselves
|
| - Wait to be Pipped or something.
|
| What exactly is the value provided by a manager?
| dagw wrote:
| So the developers take on the responsibility of a manager so
| they don't need a manager? The value of a good manager is
| that they can do some of the stuff on that list so the
| developers don't have to (ideally including all the
| 'fighting').
| nine_zeros wrote:
| > So the developers take on the responsibility of a manager
| so they don't need a manager? The value of a good manager
| is that they can do some of the stuff on that list so the
| developers don't have to (ideally including all the
| 'fighting').
|
| Incompetent managers fail to unblock their teams and
| instead push pressure on their reports to "fight". Often
| blocking career growth, promos, compensation changes with
| these reasons.
|
| I'm sorry. If the dev ultimately does this work, the
| manager should be fired or made an IC where they can
| demonstrate their value.
| andrekandre wrote:
| What exactly is the value provided by a manager?
|
| the illusion of a management structure.... ive seen it a few
| times in very dysfunctional corporate cultures where they
| value the illusion more than the reality...
|
| in those cases the managerial "class" is more like an old-
| boys club, and its the grunts who do the real work (and the
| boot when things go south)
| rutthenut wrote:
| That lead developer was effectively the manager then.
|
| But you can't just leave all choices to developers, there has
| to be a commercial point to it all - that isn't something a lot
| of devs even consider. Technical changes may be great, but the
| time spent on that has to paid for somehow, not just in 'job
| satisfaction' for the techies working on it...
| MattGaiser wrote:
| It depends on your company.
|
| My manager seems to defend the team from a lot of bureaucracy.
| I see his schedule and task lists and other paperwork and I am
| extremely happy to have him.
| pram wrote:
| Yes I've seen this style described as 'servant leader'
|
| My current manager was also my previous manager at my
| previous company! He is so good I literally followed him lol.
| lmilcin wrote:
| 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.
| myohmy wrote:
| 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 wrote:
| 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 wrote:
| 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.
| sidlls wrote:
| 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.
| sadmann1 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| My point is not that good management is possible. The article
| drew conclusions to which my experience is a counterexample.
| gregdoesit wrote:
| 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-
| tes...
|
| [2] https://news.ycombinator.com/item?id=25717390
| cdavid wrote:
| I think there is another powerful force that explains why so
| many managers are perceived as bad: in most companies, career
| growth for managers means moving up, and moving up is at best
| uncorrelated with managing your team well and with respect. I
| would actually go as far as it is negatively correlated in some
| cases.
|
| A lot of stuff I see about what an EM should do, on places like
| leaddev, in the well known eng. management books, those are all
| great. They cover most of what I enjoy doing as an engineering
| manager. But they also means shit for moving up in many (most
| ?) larger orgs.
|
| Part of the issue is that as the company grows in size, it
| becomes essentially impossible to correlate company success
| with certain teams. The complexity becomes such as people above
| you cannot possibly understand properly what's happening there.
| At this point, it starts to become all about managing up and
| lateraly, which takes an awful lot of time. People above you
| even has less mental space than you on what's happening in your
| org. So one trick that many senior managers will us, in
| engineering and otherwise, is to be behind some big salient
| initiatives. It is kind of a marketing trick. Do something
| visible that be associated to you.
|
| And then unfortunately the trick often becomes to leave before
| people can understand the mess that creates. But I think it is
| important to understand the incentive behind that: it is not
| because people are evil or stupid. It is just inherent to most
| large organizations. Very very few large orgs has been able to
| prevent this behavior.
| js8 wrote:
| > Works with finance, works with marketing, works with IT
| support, and should work with engineering as well... right?
|
| I think there is a variation of Gell-Mann's amnesia effect but
| for management. Everybody sees how their own manager/boss is
| mostly wrong and useless. However, when we deal with somebody
| else, for example as customers, we somehow conveniently forget
| that fact and we continue to believe that managers need to
| exist.
| jbverschoor wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| I guess it's the right example, because healthcare is a
| mess as well
| Jenk wrote:
| 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.
| paulryanrogers wrote:
| I agree managing is a skill all on its own. Yet IME it's
| easier to respect the choices or difficult circumstances when
| they come from someone who clearly knows the important parts
| at a conceptual and deep technical level.
| heisenbit wrote:
| While I agree that managing is a different skill set (have
| switched between the roles several times in my career) the
| problem with focusing on "it is a different skill set" is
| that it allows mediocre managers to get in who have neither a
| clue about the product nor about real life software processes
| but e.g. are great "agile master"s or have a sales
| background. A lot also depends on the nature of the project -
| some are more tangible and some other are very technical.
|
| We need people who know where we want to end up, can
| recognize problems, understand dependencies, can remove
| hurdles, can provide resources, can communicate, make sound
| and stable decisions, motivate and plan. Some of these skills
| are mandatory in a developer but there are quite a number of
| managers who have a surprising lack of ability to recognize
| dependencies, mentally juggle dependencies, plan and making
| stable decisions. And when they are coming from a pure "agile
| master" factory they may even not be able to communicate and
| focus on a product goal.
|
| > You are a team, so work together.
|
| I agree but there are cases where managers are such a bad fit
| that exchanging them is the only option. Two days ago I put
| out feelers to see whether others thought our project manager
| was in over his head and we needed to escalate it. Working as
| a team together was not really an option as we as a team
| would have to do all the managers work, deal with the
| overhead he was creating and still had key questions
| undecided. Yesterday I learned the manager is quitting which
| is good for everyone, clearly he was not comfortable in his
| role and had looked for alternatives. And no, there was no
| animosity from the team and he had a lot of help when he
| started. A nice guy but not a fit.
| bluefirebrand wrote:
| > 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.
|
| As long as the people calling the shots still make more money
| than I do and I am the one cleaning up the mess that creates,
| I feel pretty justified in resenting them.
| gotbeans wrote:
| This is spot on in my experience.
|
| The first thing that comes to my head when talking about
| bad management are manager positions with the power of
| taking decisions they they either don't fully grasp the
| consequences at-large of, or will not be hold accountable
| of bad results for.
| loopz wrote:
| Most managers climb the corporate ladder by leaving the rubble
| behind for others to deal with. They usually never learned to
| actually solve problems, and just scale the same tactics
| organisation-wide. This creates a culture of helplessness and
| shifts problems downwards. So they add processes to "manage"
| problems they themselves are unable to solve! The processes are
| just a cover for depending on local heroes and informal tribal
| gatekeeping, though. And so it goes on and on.
|
| You usually hear in such orgs, that they are like family, and
| in most cases you don't get hired unless someone knows you.
| nine_zeros wrote:
| Very underrated comment. The more nepotisitic/tribal an org
| is, the worse this gets. Everyone's just pushing the problems
| below.
|
| The only way around this for devs is to say No to solving
| their problems and letting management deal with the fallout
| (loss of customers/revenue)
| marktangotango wrote:
| Yes, very good comment; pity to those of who have lived it.
| I am living it now! It's kind of fascinating really, to see
| the coping mechanisms in a dying company. The people on the
| lower rungs seeming to go along with the same charade over
| and over, going through the motions. Waiting for another
| storm to pass, to get home to their families at the end of
| the day.
| [deleted]
| OGWhales wrote:
| My current manager, who is one of the best I have ever had,
| used to be dev and rewrote a lot of our systems so they were
| better organized.
|
| I think your comment explains at least one aspect of what
| makes him a good manager.
| ree-san wrote:
| Can you tell us more about what they do well? I'm a dev who
| has often been encouraged to consider management but I've
| scared of the Peter Principle. I'm keen to learn from good
| examples.
| andi999 wrote:
| But dont forget, Bezos is a business guy. Here his original
| idea: https://www.youtube.com/watch?v=rWRbTnE1PEM
| gonzo41 wrote:
| That's a good interview, kind of like the early interviews
| with Gates when his enthusiasm for the tech was really
| shining through. Its great to hear Bezos talk about creating
| value for the customer, something that I feel is to a degree
| lacking in some of the bigger startups we see these days.
| humanrebar wrote:
| > But it actually doesn't work with software engineers as well
| as it could.
|
| Part of the reason is that relatively small details have
| organization-wide impacts. A handful of services might be
| under-resourced and overdue to drop calls to legacy APIs...
| That causes ongoing effort to maintain those APIs, the outdated
| technology _they_ depend on, ad infinitum. Entire migrations
| can grind to a halt. Engineer productivity could be cut in
| half. Gaping security holes can be unfixed.
|
| Top-down solutions to those problems ("Here's budget. Fix it!")
| don't necessarily help as solving the systemic problems can
| require technical analysis to fully map from strategic needs to
| particular patches to particular projects.
|
| The people that understand systemic technology impact and the
| people who understand systemic cost and value _need_ healthy
| and active lines of communication. Passing status messages up,
| down, and across the chain of command only gets you so far.
| mason55 wrote:
| It's the idea that money/technology can fix a people/process
| problem. I see it all the time. It takes many forms:
|
| If we could just find the right magic tool then all our
| problems would be solved! Step 1 is build automation, step 2
| is define the process! What we need to fix this broken
| process is more people. These two teams have different
| goals/OKRs so they have trouble getting along, let's fix it
| with technology
|
| Technology and money are great accelerators but if you don't
| have a process that could be performed manually with enough
| people then technology is just going to make you do the wrong
| thing faster.
| JMTQp8lwXL wrote:
| Too much autonomy is too much of a good thing. You end up with
| 5 "send a email" microservices, multiple design systems, etc.
| People won't bother to look outside of there team's scope to
| see if anyone else in the company has solved a similar problem.
| Or without a culture of external contributions, people will
| make their own versions of things that are 90% identical to an
| existing team's service.
| sidlls wrote:
| This describes the org I'm in right now. The upper management
| (all former engineers, several ex-FAANG) are not only
| supportive but have explicitly reaffirmed that duplication of
| that sort doesn't matter: every team must be as autonomous as
| possible even if it leads to a high degree of overlap.
|
| And it's already biting us. There are at least two issues I'm
| aware of that are a direct result of this policy which are
| very bad. When they come to light the company's reputation
| (and share price) will very likely be harmed.
| ItsMonkk wrote:
| Fred Brooks had it right oh so many years ago. Communication is
| an exponential cost, so the more skills that you can give to a
| single person, the more they can do.
|
| But it's even better than that, as every time communication
| occurs you are playing a game of telephone with translation
| errors. The essential complexity might be very easy, but when
| you need to translate that problem from users to project
| managers to architect to developer(and I'm sure many teams have
| many more layers than this) the complexity grows out of
| control.
|
| I thought about this topic when the StackOverflow blog on Scrum
| ruining great engineers came out[0].
|
| Imagine you have a chart where the x-axis is trust, and the
| y-axis is skill. x-axis at the far left is management focused.
| x-axis all the way to the right is developer focused. x-axis in
| the middle is mutual trust. bottom y-axis is no skill, top
| y-axis is extremely skilled.
|
| Now let's look at some of the spaces this chart provides. If we
| start at the top right, we have Professors. They have a lot of
| skill and have tenure to be able to do what they want. On the
| bottom right, I imagine something like Adam Sandler's character
| from Billy Madison(1995), a son of a billionaire who wasted his
| life and had no productivity.
|
| On the bottom left side we have government contractors or
| outsourced developers. They do the work they are told to do. In
| this spot Scrum can be a reasonable way to filter between the
| very least skilled workers and someone who is doing decent
| work. But by applying Scrum, you are naturally holding the
| management axis to the left.
|
| The Top Left doesn't exist. The developer leaves for some place
| better.
|
| So now we can talk about the middle. At the top of the middle
| we have Skunkworks projects. And as we can see, this balance
| between management and development can yield incredible
| results, if the developers have the skill to back it up.
|
| So we can see there is a careful balance, most developers are
| probably somewhere in the middle "strike zone", and by applying
| Scrum to a developer who is highly skilled you are handi-
| capping them, and if you apply to much force they leave for
| better pastures.
|
| When you have developers in this strike zone, give them advice,
| allow them to learn, but let them make their own decisions.[1]
|
| [0]: https://stackoverflow.blog/2020/06/29/does-scrum-ruin-
| great-...
|
| [1]: https://jessitron.com/2021/05/26/a-high-resilience-org-
| chart...
| trentnix wrote:
| > 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)
|
| I think that's part of it, but the bigger reason is that the
| management talent pool is too small to meet the industry need.
| The same is true of engineers as well.
|
| There's little apprenticeship, little mentorship, and little
| experience is gained seeing things done well. Capable people
| are being shoved aggressively and prematurely into decision-
| making roles (whether in management or engineering) before
| they've developed the skills and perspective necessary to do
| the job well. No question, talent scarcity makes for lucrative
| pay and easy mobility for the average tech professional. But
| quality suffers, nonetheless.
| abeppu wrote:
| I think it's more than lack of experience with great
| engineering culture. I think bad management is actively
| incentivized by a spandrel of how our organizations fit
| together. There's a mismatch between the time it takes to yield
| measurable impacts and the time scale on which rewards accrue
| to individuals. Because large and complex projects take time,
| and are hard to measure, and it's hard to attribute the portion
| of success or failure to an individual, when three quarters in
| a manager is promoted to some new position which the CEO thinks
| desperately needs to be filled, it's off of the narratives the
| manager has been able to produce, not the actual impact. The
| tools for making a narrative of competence and success are
| understandable, punchy process and organizational improvements,
| cherry-picked measures that don't really mean anything,
| meetings, 1:1s.
|
| So, when a sequence of directors each wants to "refresh" how
| the planning and prioritization process works, or reintroduce
| OKRs because they believe that what the org was doing up until
| that point was an incorrect, or champion some new set of
| Principles that obligates all existing projects to re-justify
| their existence in new terms, or move all project management
| into a new tool, they're creating a narrative of leadership.
| And they can tell a good story well before the non-impacts
| become visible, and without having to examine or deeply
| understand the technical aspects of what it is they're
| managing.
|
| In some cases, this can be a modest productivity tax to the
| impacted teams. Some number of weeks from every quarter gets
| dedicated to servicing the most recent process changes etc. But
| sometimes it's actively harmful (creating separate silos for
| functions that really need to be in close coordination, etc).
| qrbLPHiKpiux wrote:
| So, developers want a blank check, is what I'm reading?
| lifeisstillgood wrote:
| I think he just invented Developer Anarchy
|
| https://www.youtube.com/watch?v=tIxHmsWCd7g
|
| Honestly I just call this Software Literacy.
| nickthemagicman wrote:
| 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 wrote:
| 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 wrote:
| 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.
| orsenthil wrote:
| 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.
| ineedasername wrote:
| 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.
| unknown_error wrote:
| I think you're conflating diversity in skillsets with corporate
| hierarchies. I think the article was less about devs vs
| marketing vs any other dept, but rather about managers as a
| distinct class above all the rest, with all the decision-making
| power.
|
| Different depts having a seat at a table is great if your org
| is flat enough that the table is actually the group making the
| decision. If their decisions just get overridden by middle
| management, it's back to the same problem again: not that there
| are too many depts with their own limited perspectives, but
| that managers with little to no technical background are making
| decisions that affect their more skilled minions, typically
| without their minions' buy-in.
|
| The problem isn't any particular skillset, but the professional
| managerial class whose management skills are too often dubious
| to begin with, unmeasured, untested, and yet prioritized over
| technical skills, be they marketing or HR or dev. Some orgs
| help mitigate that by having a feedback loop for their managers
| and the ability to underlings to skip a step or provide
| meaningful feedback that can result in the discipline or
| "impeachment" of someone above them, but that's the exception
| rather than the norm. In most orgs I've seen managers are
| recruited from other management backgrounds horizontally
| instead of rising up the ranks from a technical background.
| Maybe the intent is to recruit better people-people instead of
| super-smart devs who don't understand humans, but in my limited
| experience that rarely works past a certain tiny scale...
|
| Most don't have "tables" to begin with, just thrones and
| various forts.
| ineedasername wrote:
| I understand what you're saying, and had the article put it
| in similar terms I wouldn't take much issue with it. Instead
| the article took the tone of developer superiority vs.
| managerial incompetence & intransigence. Where, by
| implication if not direct statement, all failures are
| failures of management.
|
| I don't like that management gets bashed so consistently,
| because it is a view blinded from the truth: good management
| isn't actually all that rare as this POV would make it seem:
| Good management is nearly invisible. It smooths over things,
| putting fewer roadblocks in workers ways, and thereby only
| gets noticed when there's a problem. And even the best
| managers will encounter problems, meaning people really only
| take note of management when there's something negative going
| on.
|
| Maybe it's because I've had all three types that articles
| like this put me on the defensive. I've seen bad management,
| I've seen invisible management that generally makes my life
| easier in ways I only notice because I've had bad managers,
| and I've had at least one manager that was so good that they
| not only made my life easier, they made me much more
| effective at my job.
|
| Rising through the ranks is also no guarantee of success:
| management is a skill, and it does not always overlap with
| being good at the jobs you manage. All that does is make sure
| the manager understands the work, not actually understand how
| to manage a group/department/division etc., Which is a
| different skillet. I'm not a manager, despite opportunities,
| precisely because I understand that fact, my own preferences,
| and my own limitations.
|
| It's also important to remember that "bad management" is
| frequently not monolithic. There may be very good managers
| throughout an organization, but one bad mid-high level
| manager makes them all look bad when even after they fight
| back against something,they lose the fight and their job is
| still to implement it. No different than an excellent
| developer forced to write something useless/bad/inefficient.
| Is the developer a bad developer? There are some fights like
| that-- won or lost-- that I've only found out about long
| afterwards, because again: good management is often
| invisible.
| unknown_error wrote:
| Those are very fair points. Yes, good management can make
| projects (and people) function more smoothly, and yes also
| that it can be a thankless job that only gets noticed when
| something goes wrong, not for all the times it goes right.
|
| For all those reasons, it would be nice of the skillset of
| management could be decoupled from the hierarchy, pay, and
| prestige of management. Too often the "managers" in an org,
| and by the extension the CxOs, are there not due to their
| skill in managing people/projects, but more or less
| "awarded" the position as a consequence of their
| connections, founder status, length of employment,
| whatever.
|
| If only "management" could be thought of more as
| "facilitation" (or mediation, or HR, or similar) in that
| it's a unique skillset, yes, but no more or less valuable
| to a group than any other skillset -- not an inherent part
| of some hierarchical and unaccountable structure. Managers
| should not be above the people they manage, but be able to
| offer workflow & worklife improvements, help resolve and
| mediate conflicts, etc. And there's no inherent reason they
| should get paid more or less than workers of any other
| skillset.
|
| Top-down control != group facilitation skills, but present-
| day corporate hierarchies try to pretend they're one and
| the same, to the detriment of many orgs, and especially
| anyone under (visibly) bad management.
|
| A "seat at the table for all" implies a level of idealistic
| flatness that's just not there in most hierarchical
| organizations. I think it's easier to teach a flat
| organization better people and project management skills
| than to try and flatten a purposefully-hierarchical
| organization that uses middle-management not to improve the
| productivity of self-directed workers, but to corral a
| disposable workstaff who have miserable lives because
| they're thought of mere doers-of-tasks, not partners in
| planning -- a vicious cycle reinforced by the existence of
| a professional managerial "class" (as opposed to skillset).
| nine_zeros wrote:
| > 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 wrote:
| > 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.
| travisgriggs wrote:
| 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.
| agentultra wrote:
| 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.
| ornornor wrote:
| > 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.
| agentultra wrote:
| https://jaymeedwards.com/ provides some good content on his
| Youtube channel
|
| https://www.amazon.ca/Elegant-Puzzle-Systems-Engineering-
| Man... helps to understand managing from an engineering
| perspective
|
| To understand some of the history and context:
| https://www.youtube.com/watch?v=a-BOSpxYJ9M
|
| A bit dated but still useful book:
| https://www.tablegroup.com/topics-and-
| resources/teamwork-5-d...
|
| Best of all, for surviving at a difficult organization,
| invest in yourself and get a good therapist. I can't
| recommend this enough. Burnout is the worst but you can
| manage if you have solid, professional support to aid you.
| thrower123 wrote:
| 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 wrote:
| Agile is _exactly_ the corporate management hell it claims it
| was out to solve.
| jph wrote:
| 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?
| proc0 wrote:
| Or... managers could do this translation themselves, by first
| learning how to do the technical work. My personal gripe is how
| much we have to chew and digest things for the non-technical
| people. The managers that know how to solve the problem
| technically would not ask this as much, but maybe then they
| would also be writing code as that is always needed.
|
| I feel like managers that can't understand the technical part
| are the one to ask for this "translation", and because of that
| the technical people get a significant overhead in work, and
| because of that more people are needed to do the work, and that
| in turn creates more need for more managers. It's like a
| vicious cycle that could be mitigated if everyone knew how to
| do the technical part, and for this to happen I think companies
| should start making programmers the managers as much as
| possible, but I guess that won't be happening anytime soon (but
| I'm sure it will in the future once programming becomes
| widespread enough).
| ClumsyPilot wrote:
| 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 wrote:
| 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 wrote:
| 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
| protomyth wrote:
| 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 wrote:
| >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 wrote:
| 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.
| grepLeigh wrote:
| To understand the angle of this article, I looked for what this
| site is selling: 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.
| taeric wrote:
| 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.
| MelvinButtsESQ wrote:
| I can't help it: https://www.youtube.com/watch?v=fcIMIyQnOso
| codebolt wrote:
| 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 wrote:
| I can also recommend this book (it's on Audible too and a great
| listen).
| proc0 wrote:
| Check.
___________________________________________________________________
(page generated 2021-06-10 23:01 UTC)