7 ms·

After being in a large company for ten years, I’m convinced that managers and companies don’t want productivity from their employees, what they want is alignmen

• LanceH 4y ago
  There are a lot of people who prefer proof of work over work.
• jack_riminton 4y ago
  -deleted-
  • bytehowl 4y ago
    I thought execs had to do all the cunty things they do because "it's their legal duty to maximize profits for the shareholders"? But suddenly it's OK to sacrifice productivity for the sake of power-tripping? Shouldn't he have been fired on the spot?
  • tester457 4y ago
    > "I want to see people and I want to see people jump through hoops for me". Nauseating.
• greatpostman 4y ago
  When I was younger I always assumed all the tracking had value. After a decade of working, it’s all a facade. And all these people are constantly trying to be managers which explodes the amount of documentation
  • A4ET8a8uTh0 4y ago
    Some tracking has value. Last year I did some testing. Its results were recorded for posterity. A year later, for god only knows what reason, production environment differed slightly from testing environment a tiny little bit. Records allowed for a relatively quick follow up with vendor and resolution. But it goes back.. how do you know something will be important?
    • Kamq 4y ago
      Can I ask how people found it a year later? Everything always ends up on a confluence dumping ground, and I have trouble finding pages I wrote after any sort of significant period of time, much less finding things other people wrote.
      • A4ET8a8uTh0 4y ago
        To be honest, I think it is my history with the vendor. I know them to be flaky so I keep anal documentation of minute changes one version to the next. It is genuinely just an excel spreadsheet, but there is a focus on changes they introduce along with dates since I was burned before. The issue was fairly unique and actually tested for and the list of implemented defect fixes in testing env. was listed on our end ( and maybe for once the fact we don't use confluence helped ), which helped to narrow it down on the vendor's side ( I am not sure what they use internally ) and it certainly helped that there were only two related projects for that specific move for the date the issue occurred. FWIW, it is possible that I am just still relatively new to this ( 3 years for the testing part ) so all the issues we experience don't all blend together yet. edit: Apologies, as I re-read it, my response feels fairly generic, but I am not sure I can discuss more details.
        • Kamq 4y ago
          Ahh, I see. I think I can see the value in tracking kept by a person for themselves to troubleshoot things in the future. But I can't imagine that's the kind of tracking greatpostman had in mind, and it's definitely not the kind of tracking that most managers I've worked with try to produce.
• AdamJacobMuller 4y ago
  But what's the point of productivity if you aren't working on things which align with larger goals of the organization? You can be the busiest person in the company, but, if your doing work which doesn't align with the goals of the company your contribution is either useless or in many cases is actively harmful.
  • YokoZar 4y ago
    Sounds like the company's problem. Maybe they should change their incentives so that managers actually want the right things.
    • lolinder 4y ago
      Why are you so sure that legibility and alignment are the wrong things to look for in a large organization? Most of the work in a large software project is coordination between all the minds involved. The more minds, the harder this task is. Large companies don't need people who can work super productively but might work on the wrong thing for weeks before surfacing again.
    • sigstoat 4y ago
      > Maybe they should change their incentives so that managers actually want the right things what's the incentive structure for mid-level managers that maximizes productivity, but doesn't have the managers whipping the staff to work harder?
  • Cardinal7167 4y ago
    I think what OP means (and I would be inclined to agree) is that companies will take significant cuts to productivity in order to feel more secure and informed of the progress, even if that feeling is not grounded in data.
    • serial_dev 4y ago
      The word you are looking for is micromanagement.
• throwaway689236 4y ago
  The bigger the company, the less effective it is.
• Spivak 4y ago
  I feel like everyone acts so surprised at this like it’s some contradiction when it’s exactly purposefully right. At the end of the day delivering results isn’t the end all be all. It’s delivering the right results on a known and predictable time scale without any surprises. Above a baseline of speed it doesn’t really matter because you’re only as fast as the slowest business unit involved in your release and it’s not usually engineering. Realistically my team could push out features that could fill a newsletter every single week but the parts of the business that figure out what features customers actually want, how we can market and sell them, how we tell users about them, getting them through qa, gathering incremental user feedback for the next iterations all work on human time and so we directly (or indirectly through management) get pulled into those concerns. I think lots of devs feel weird about coding for 20 or less hours a week because it’s the part we associate with work when in reality we’re delivering real business value in those stupid meetings, it just manifests outside our view. Dumb Hack: Treat meetings even ad hoc ones like card work, groom them, assign them point values, define ACs and retro them. You’ll discover really quickly the meetings that aren’t serving you and the value you’re providing to the rest of the business.
  • opmelogy 4y ago
    > ...delivering results isn’t the end all be all. It’s delivering the right results on a known and predictable time scale without any surprises. Well said. I've had a hard time articulating this but you nailed it.
  • catiopatio 4y ago
    > I think lots of devs feel weird about coding for 20 or less hours a week because it’s the part we associate with work when in reality we’re delivering real business value in those stupid meetings, it just manifests outside our view. Blink twice if you’re saying this under duress, because otherwise, this just sounds like post hoc justification from someone who gave up and dedicated themselves to promulgating the soul-sucking management games that made producing real value untenable. Spending less than 20 hours a week actually writing software is a horrendous use of a developer’s time. It’s a marvel when anything intelligent gets written at all in such an environment.
• zmmmmm 4y ago
  Absolutely ... for large organisations the key is scale. When it comes to staff in strategic roles (engineering, software, etc etc) that build capability, there's a point where the challenge of growing past a certain scale completely depends on substituting individual action (aka productivity) with organisational ability to deliver results using any number of employees, where that number doesn't really matter any more. And that depends far more on the things you mention - clarity, alignment, procedural coherence, etc than getting even 2x more from the individuals involved. It's funny because software engineers will be the first to tell you that "premature optimisation is the root of all evil" and other similar mantras but then be perplexed that their own individual productivity isn't the first item on their manager's agenda. The manager is probably busy optimising something else.
  • vlovich123 4y ago
    I would argue that your innovation center should be staffed primarily focusing on productivity rather than scale. You can always add scale as needed but you can’t add productivity once you’re at scale
    • Tyrek 4y ago
      There are productivity decisions at the micro-level that actively hurt scaling. The easy business example here is the choice to manage data in Excel as opposed to a formal database. (Very common in financial orgs). Excel gives the team today much more flexibility, at the trade-off of risk (anyone can edit numbers) and scaling (other teams probably can't find your excel file).
      • zmmmmm 4y ago
        > There are productivity decisions at the micro-level that actively hurt scaling Probably the most obvious one that HN readers will be familiar with is the 10x developer who trail blazes out amazing software but even if they do document it well, it generates an unsustainable technical foundation because it can't be supported after they move on (whether internally or externally). In a startup, this person is invaluable. In a large organisation you may even screen them out at interview stage in certain contexts.
• alexashka 4y ago
  'Productivity' is just a term higher management tells lower management to make them believe they can get promoted. Not unlike organized religions telling folks about heaven. The best lies are always audacious - people can't help but want to believe them :) That this results in holy crusades, witch hunts, daily stand ups and open offices - that's just part of being a homo sapiens sapiens.
• markus_zhang 4y ago
  I actually think both are important and pretty much define what real productivity is. Since the company pays me dough surely it has a say in what I should work on. And a bonus if manager can pull his weight to make things happen, i.e. management intervention. My current manager works like that and I'm perfectly fine with it. The only issue that I can see is that said manager might drastically misunderstand the scope of things at hand. But so far I haven't met anyone like that.
• marcus_holmes 4y ago
  This is why I hate working for large companies. It's all about the politics not the craftsmanship.
• nostrademons 4y ago
  That's literally a manager's job. If you don't have managers, by definition, you have individual contractors. The point of being a manager is to line up the work of all the ICs so they are more or less pointing in the same direction and can tackle problems that no one person could handle on their own. There is always a productivity cost to this, and it takes many forms. One is simply the manager's salary: they aren't doing useful IC work, they're spending all their time aligning their reports' work with the goals of the organization. Another is that the ICs will typically be working on projects that align with their organization's goals rather than their own goals, and most people are less excited by a faceless megacorp's goals than their own personal projects. A third is that all the communication overhead and status reports come out of time that could be spend actually working. A fourth is that you're often forced to adapt less productive methods, programming languages, frameworks, etc. simply so that what you're doing can be communicated with other employees. But this is all intentional, and savvy businesses know it's going on. It's the cost of being a big business, and you usually can't become a big business unless you can solve problems that smaller businesses cannot. A corollary is that a good manager usually doesn't care much about how productive you are, only that you have positive productivity and demand little of their time & energy. If they manage a team of 10, your productivity could be 1/10th theirs at the same task, and yet be a net win for them (and the organization), because the team's output is more than they could achieve on their own. However, if your productivity is half theirs and you take up half of their time with your questions, it's easier for them to just do your job, and now you're a performance problem. And conversely, if your productivity is double theirs but you're a jerk that demotivates the other 9 employees, they're better off letting you go even though you're a superstar, because their team productivity is 1/5 what it would with the other 10 people on it. This is why there's often a lot of counterintuitive behavior in large organizations. Your manager knows that you're reading HN on company time, or taking personal calls, or arranging doctors appointments. They don't care; you'll make it up later, and it's usually a net productivity gain to make sure employees are rested, happy, and healthy rather than squeak out every working hour from them. Same if you want to take off an hour early for childcare. But conversely, if you're putting in long hours and cranking out tons of code but you're a jerk that makes the rest of the team stressed and anxious whenever they come into work, you are a net productivity sink and will probably get let go. It's even worse if you're putting the company at risk through HR violations, negative PR, stealing trade secrets, etc - which is why even prominent high-performers can get fired for that. The bigger the company the higher the downside, and hence the greater the tendency toward mediocrity. In a startup your bad attitude, loose mouth, or penchant for lechery might be tolerated because the potential upside outweighs the risk to a company that's probably going to fail anyway. In a megacorp there are 200,000 other employees that can do your job, so a.) your productivity has to be pretty bad before you're a net negative to the organization and b.) your potential negative productivity caps out at 200,000x your salary, which means it doesn't take much of an infraction against the company before you're terminated.
• crazygringo 4y ago
  But alignment and legibility are productivity. 10 employees working fully aligned will achieve much more of what is valuable to the company than 10 employees working just as hard but on things that don't sync up right. And legibility is needed in order to achieve alignment. A manager needs to make sure all the parts of a project come together by the deadline, and so tracking progress allows them to quickly say OK let's drop that feature or I need to unblock you on this so I'll reach out to the other team's manager. Productivity isn't a scalar quantity produced by employees that simply adds together. Think of it as something more multiplicative, where a "zero" from a key employee tanks a project altogether. (E.g. your team of nine back-end engineers and one front-end engineer achieves zero productive output if the front-end engineer doesn't deliver anything workable. Or the back-end database engineer fails at their tasks.) So alignment and legibility aren't detrimental to achieving objectives -- they're critical.
• jawns 4y ago
  > I’m convinced that managers and companies don’t want productivity from their employees, what they want is alignment and legibility. That's like saying managers and companies don't want productivity from their employees, they want developers to write lots of tests under the guise of making code more robust, lots of documentation under the guise of making it more maintainable, and do lots of code review to ensure it meets the team's standards of quality. If we didn't have to do all that testing, documentation, and code review, we'd be able to move a lot faster! Speed and productivity aren't synonymous.
• btbuildem 4y ago
  > what they want is alignment and legibility Having worked in all sizes of companies, I've learned this: bad managers want obedience. I've seen this from team leads, from C-suite, and in between. For me it's a huge red flag, a sign of incompetence and of an offensively domineering mindset. Good managers want communication (or as you said: alignment and legibility).
• firstfewshells 4y ago
  The 2 most important traits that managers desire are agreeability and subservience. Never argue with them. Even the slightest of power corrupts humans.
• akeck 4y ago
  It seems these days that using Jira is primarily about making work legible in large orgs.