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.
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.
what's the incentive structure for mid-level managers that maximizes productivity, but doesn't have the managers whipping the staff to work harder?
Assuming larger goals on the level of "profit", sure. There's no point.
But alignment that people harp on about tends to be on specific business initiatives, or possibly KPI targets (generally tied to executive bonuses). This sort of alignment is how you get an alignment trap (where teams that are more aligned actually cost the business more and deliver less value than teams that are less aligned).
I also hypothesize that when you have systematically low productivity, the business/product no longer becomes aligned with the market. In that situation you actually don't want your employees to be 100% aligned with the business.
I suspect that the guy who invented gmail (or rather linked ads to the text), had he asked his manager would have been told "hell no, fix the javascript bug that's assigned this week - that is putting us behind target for the month"
I generally think one should measure new or increased capability as opposed to most other metrics.
How is an interesting question
The history of gmail is that it started as what Google called a 20% project. A side project the developer, Paul Buchheit, worked on with the knowledge of his managers and peers.
But it goes back.. how do you know something will be important?
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.
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.
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.
Nauseating.
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 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.
Well said. I've had a hard time articulating this but you nailed it.
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 if anything intelligent gets written at all in such an environment.
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.
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.
My team is the heart of my company's innovation center and we've very intentionally sacrificed a lot of productivity for alignment and it's been really good for the business. It's an internal platform with probably another ~20 eng years of work left, turns out the bits of work our team thought would be most impactful weren't. By focusing on alignment we've been able to sequence the work so that more of company gets onboard early and the company as a whole delivers more value, faster, with less long term debt.
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.
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.
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.
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.
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.
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).
Alignment being: we both agree on what you should be working on, and legibility being: are we on track, or do we need management intervention to ensure completion? Emails, status meetings, stand ups, pop ins, IMs, while detrimental to achieving objectives, satisfies management desires.