If you are a "delivery driven" person who cancels holidays to keep working, I would say to you, from own experience: stop being stupid.
I know, that, specially when you get recognised for the hard work it is hard, but you will regret every minute.
If you work for a company that counts on your holidays and vacation to sell their products, you are helping to create the problematic world with have today.
If many do that, more will need to do. If none do it, and act like it is an absurd to request it (and it is) nobody is forced to do it and the company is forced to do real estimates even if that hurts your fav CEO pocket
Unless you are getting the economics of saving the day (you are a large equity holder / partner) then structuring your life completely around work is a fools errand.
Communicate your holiday plans, arrange coverage, put it team calendars, do hand-offs.. and then take it. Projects come & go, dates slip on their own. If you move holidays for project dates you will never take holidays.
The only exceptions would be if you are in a role with seasonality and its generally understood end of year / end of quarter / tax time / something is well known busy season and its in poor taste to disappear during it.
> Unless you are getting the economics of saving the day (you are a large equity holder / partner) ...
Even if you are a large equity partner it's at best short-sighted. I have written about this before[1] but the gist of it is that even when individual heroics saves a project it has robbed the project manager of valuable feedback regarding how the planning was deficit.
>The only exceptions would be if you are in a role with seasonality and its generally understood end of year / end of quarter / tax time / something is well known busy season and its in poor taste to disappear during it.
This is exactly how you get guilted into working during vacation; everything is sold as an exception.
> structuring your life completely around work is a fools errand.
Structuring your life completely around anything is a fools errand — work, video games, family, food, etc.
Unless it’s not. Maybe the only thing you care about in the world is your family and you’ll ignore everything else. Maybe video games are your truest passion and you’ll do whatever it takes to play them 80 hours a week.
Maybe I love CRUD apps and Jira as much as my next door neighbor loves his wife. Who’s to say?
If you want to devote your entire life to one thing, go nuts. It’s probably going to have some consequences whether that thing is work or not.
Its useful to do the math around what your equity would be worth, if you are the 50th hire you are probably getting less than .1%, so even a crazy moonshot billion dollar acquisition would leave you with a few 100k at most. Grinding yourself down for a slim chance at making that amount isn't worth it.
I have had managers say things like: "this could be the last job we ever work" as if none of us are capable of doing math.
That said we are all a bit prideful so exhausting yourself to get that fleeting feeling of having achieved something clever and good is definitely on the table.
Companies will also never remember your hard work when it comes to layoffs. My cousin worked until 1am almost every day from September 2023-January 2024 to complete a poorly managed project. He only had Christmas off because the director thought employees would sue as it is a religious holiday. He missed important events and lost about 20 pounds, because of stress.
The company had a hard deadline to move over to a brand new system. They had 5 years notice and decided not to start it until the year before. If they didn't make the deadline, it would mean millions of dollars in costs because it was outside the contract.
Him and his team made the deadline. His reward was being laid off a few weeks later as his position was eliminated. Now he's over 50 and trying to find work in a terrible time to look for a job.
It’s not that I have nothing else to do. It’s that the dopamine hit of fixing a thing that affects my team often outweighs any other choice.
Working out frequently, getting a family, getting a side project off the ramp, and reducing to part-time have all helped me with my addiction to feeling valuable and important when nothing else is gained than becoming known for fixing stuff in weekends free of charge.
This is not a great take. I have plenty of things to do outside of work and I will still do what's "right" in my mind, especially if there's enough evidence that it will make my and other people's life easier in the long run.
There are plenty of people like that in a company but they normally don't cluster together, so it feels like "nobody else cares". That's false. At times that's how exactly how products, or even entire companies, are saved. Because a bunch of individuals who think like that get together and work hard to accomplish something.
Whether that effort is recognized or not depends on the company. If it's not then, I agree, it would be irrational to keep pushing. But you can't know until you try.
(Edit: to be clear, I'm not advocating prioritizing work over anything else, that really depends on you, but there's a fine line between "working hard" and being obsessed. The latter will more often than not result in a net negative in most cases. The same level of effort and/or prioritization should be applied to all areas of life)
I remember a company meeting where a series of employee recognition awards were given out, and the story for about four awards in a row was an employee who spent nights and weekends heroically fixing a giant mess, at least enough to make a deadline. In a couple of cases the employee who got the award was also partly responsible for the mess. After about the fourth one the top managers in the room finally got it that the company had a problem.
I remember an awards occasion where the employees who received the recognition for actually heroically fixing a mess could not make it to the stage because they had been laid off.
[edit: I retract my comment that it's bad advice to not cancel holidays to work hard. I misread the comment that I replied to -- I had thought the commenter was saying don't work extra hard in your role as it's never worth it. That's not what the commenter said though. In my experience, people who produce more value in the world are more valuable and get rewarded more than those who don't.]
I think this is poor and dangerous advice for anyone who wants to get ahead in life. If you are happy to coast by and not achieve much in life, sure, don’t work hard. But if you want to be one of the few who either rise to the top in your field or to create value in the world, then don’t feel bad about wanting to work hard. People generally learn by doing and those who do a lot learn a lot.
Of course, don’t prioritize it over things that are important to you (physical health, family etc) but don’t feel it’s wrong to prioritize it above stuff isn’t important to you (eg Netflix and YouTube shorts).
I think the difference between someone who "gets ahead in life" and someone who doesn't usually isn't the number of hours spent in the office. Usually its more related to how well you make decisions in your career, and the relationships you build along the way.
Go to therapy. Learn about yourself. Work on your communication skills. Figure out what matters to you and invest in it. (For most people, family and friends are high on that list).
By all means work hard, but be strategic about it. Martyring yourself for your company won't make people respect you.
There's several game studios out there whose last two tweets were "we've just won an industry award for our game!" / "our studio is being shut down immediately".
It's worthwhile working for yourself if you do think you're learning, but in today's corporate environment loyalty is just showing your willingness to be exploited.
What do you mean by "getting ahead in life"? That you pass more time doing stuff at work so you are closer to your death without having done the things you like, spent time with the people you love and visiting the places that fill you with joy? Or do you mean money? I am pretty sure if you are good at your job and you are not in a dying profession there will be enough places that show you the respect you would extend to them.
Shilling for work place abuse and unpaid overtime isn't getting you ahead in life the same way begging for forgivness with an abuser will make your life better.
If your corp can't manage people's time realistically, why would you expect them to manage anything realistically? Get out and go to a real place that knows how to run projects.
Don’t ruin your health for someone else. People who throw themselves on this fire in BigCo don’t get recognition or reward, they get abused by the political animals that will take advantage.
Work hard for yourself to build your own. But don’t think for one moment that death marches will result in a swift rise to the top.
I've been the person working stupidly long hours for many years. Eventually I stopped doing it, and I started to set boundaries around my downtime, and I found out something really valuable: Nobody noticed a difference in my productivity. I was doing far less, but nobody noticed. They all assumed I was still as busy, and doing as much, and it's because the things we all do to be super busy and productive ARN'T productive. You might ship some things faster, but the quality suffers, changes are harder to make later and everyone's tired all the time.
So no, "working hard" won't get you ahead. The people who really get that far ahead in life are the ones networking and learning the political games, not really working. And why do you need to "get ahead" to be successful? I'm ambitious, and I love growing in my career. I'm not someone who is happy with the bog standard things, but I've also learned that when all you value is being ahead of your peers, you miss out on more than you gain. And on top of it, you all end up in similar roles anyway.
One can work hard and still not cancel holidays for work. Plenty of people work through holidays and don't "achieve much in life". I've known many people in higher positions who use all of their time off.
> one of the few who either rise to the top in your field or to create value in the world
"rising to the top" is pure ego-inflation
"create value in the world" -- you'd better make sure that you're creating value for the world in something that's important and meaningful to you, not just "create value for shareholders" (who don't give a f about you) which is what "creating value" means 90% of the time if you're in industry
Achieving a lot in life is not necessary about working hard. Its more about working smart or having a bit of luck. None of the successful (money wise) people arround me worked really hard. The working hard sentence is really nonsense.
>I think this is poor and dangerous advice for anyone who wants to get ahead in life.
Oh yeah, every new-comer to the tech world thinks like this, and 99.99% of them don't get any further "ahead" in life than the rest of us. In fact, many end up further behind.
Why should that person sacrifice themselves when they are happy working? Just so other people are not held to that standard? That seems like a management issues. Don't expect the same things from everyone.
Any impressionable kids reading... this story playing out like it did is highly company-dependent, as well as luck-dependent.
In a healthy company/organization:
* That outsourcing implementation approach probably wouldn't have happened, because an experienced person could've guessed how that would turn out, before it was started (it's such a cliche).
* Earlier on, people would tell the CTO it wasn't working out, instead of lying and saying the opposite.
* Whenever they needed to do something smarter/creative to rescue the project, they could work with the CTO on that, and maybe even with the customer.
* There wouldn't be marathon whip-cracking over the holidays, especially not after the team was already burning out.
* A manager/lead would go to bat for the success of the project and the health of the team, and insist upwards that the team needed a break over the holidays, if that needed to be clarified.
On that last point, in a "half-healthy" organization, a manager might intentionally be very vague, and omit information. That happens, and might or might not be a good idea, depending.
But the way this story is told, it sounds like the manager/lead outright lied repeatedly up the chain of command, which is generally considered very-bad, in both healthy and unhealthy companies.
I'll add that these things are vastly easier to armchair-quarterback. Certainly we're all going to make mistakes, especially when put in difficult positions, and/or when overextended/fatigued. But it helps to look at scenarios, to try to learn from them, and to think from a distance how they might've been handled better, so you're armed with that "experience", the next time you're tossed into a rough situation that has some similarities.
The worst problem is, every success will be credited to CTO and every failure will be aimed towards the manager because it's a disobedience. In this case, the CTO also reward the credit to his friend because he/she doesn't know the backend.
In the short time you may save the company, in the long time you'll lose and the company will lose too.
"Because the CTO had a yearly turnover of his direct reports, every status call about the project took some variation of “great idea, boss” even though literally no one involved thought it was even a good idea.
Or even a mediocre idea. It was a bad idea"
But if everyone confirms his bad decisions instead of pointing flaws out, then they are all part of the problem.
I worked at a shop where 2 layers of management decided they didn't like to see red on RAG status reports and wanted to discuss "changing the definition of done" for projects to preclude you know.. actually shipping them to prod.
Former company of mine got a board member who pushed his "solution" on us, and it fucked up so much of our ordering processes, things we didn't even SELL were being shown. It took a year and a half to fix this, meanwhile it also meant we were unable to reverse a sale because "underwear" was shipped out and we can't cancel it (meanwhile, we don't sell underwear, just networking services). So we had to wait for the system to close out the ordering process and THEN they could assist the customer. Of course, that board member left a year later, Probably very pleased with himself for suckering our idiot CEO.
But that's ok cuz I got laid off of there, and I have no sympathy for that bumbling company. Idiots trying to outsource "solutions" that only added more pain for everyone.
Sometimes these are actual problems that need solutions but half the time ... It's just more crap to make themselves feel like they're "saving money but not building in house". Yeah just now you have to pay contracts to support the crap you never built in the first place. Good job. Golden parachutes for all the leaders, I guess.
To be honest, I'm wondering where all these cartoonishly unhealthy companies come from. I've worked in a bunch of companies in my career, and sure, at pretty much all of them at one time or another I may have thought "are you f'ing kidding me?", but that's really just the nature of large organizations.
And perhaps I've just been lucky, but in 25 years in tech I've never seen the level of gross incompetence described in this post. I'm truly envious of the vast majority of senior leaders and execs I've worked with - not because they're geniuses or anything, but because they excel at things that I find very challenging (and I know from my stint in management) and I learned a lot from them. Again, not everyone, but I've certainly had more good bosses than bad.
Many of the top companies you know were that healthy company once. You basically need to be one at that magical inflection point where the growth will crush you if your engineering is not empowered and on point. Especially back when clouds didn't exist, or were far less featureful, so turning dollars into horizontal growth was not a thing.
The dark secret is that being a healthy company is just a moment, not something a company is at all times. Staying a healthy company as you grown when you are actually successful is very hard, and once the health is gone, good luck regaining it, because now you have a lot of people that thrive in unhealthy environments.
I have close to 15y of experience now, and I've mostly only worked on healthy companies - I can think of 1 that wasn't. I have worked in ~8 companies give or take.
I mean, nowhere's perfect, but I don't think I've ever worked anywhere as dysfunctional as the company depicted in the article. That's really quite bad. If the place you work is like that, consider applying elsewhere; this is not typical.
> Earlier on, people would tell the CTO it wasn't working out, instead of lying and saying the opposite.
I have done this, also have brass balls and dont give a fuck. EDIT: I mean tell the truth, so rare to not hide the fuck up. See MS security memo.
> There wouldn't be marathon whip-cracking over the holidays, especially not after the team was already burning out.
Ha ha ha ha ha... Ok this is partly true. IF you work in a BANK or in a FAANG then yes. If you work in any company that has "startup culture" forget it. The thing is that skin in the game (real skin) will change your attitude about work pretty quick. I dont think there are many companies where you will get it and have the opportunity to see that.
> But the way this story is told, it sounds like the manager/lead outright lied repeatedly up the chain of command, which is generally considered very-bad, in both healthy and unhealthy companies.
Do you know how many times I have been the cowboy who got some shit done in the dark of night cause it needed to happen? Most of the people I know who are good have gone this route. Hell I have seen these sorts of things happen AT A BANK.
Bend all the rules past breaking but tell no one. As long as you aren't making a huge fiscal bet (aka more than the company or your teams value) then your gonna get away with a lot. You either do it and get promoted or you get a new job (cause you limited your ability to get promoted).
> If you work in any company that has "startup culture" forget it.
Depends what "startup culture" is.
I actually did an early startup work marathon over Christmas, to help pull off a minor miracle, and make a very hard launch date successful.
But during the same period, I also managed the tasking/planning to shield a key teammate who'd gotten sick, and take stress off of them.
> Bend all the rules past breaking but tell no one.
I think that depends on the company, and the kind of rule.
In some companies, rules tend to be there for a reason, and if you break a rule, you generally have to disclose that, and maybe discuss it (ideally beforehand).
Even the healthiest large companies do this sort of thing, I've worked in a few and heck I've sold to a few too. Low code solutions that somehow need a team of contractors to deliver business functionality, delayed projects that drop key integrations to deliver something on time but functionally useless, CTOs whose next job depends on giving work to supplier. Worst of all, organisations that insist that they buy not build but then have larger software teams than their suppliers.
> The vendor product stored every customer transaction as a json record in a giant json document.... Adding a new transaction involved reading the entire json document out of the database, then appending the new record to the end.
Does this sound insane to you? Obviously it should, but in the vein of "insane things" I was helping do tech diligence of a potential investment for a fund. The startup's users table also contained the "tickets/booking" data. Each ticket was a column. So if your most active user had 5 tickets in total history, you needed 5 columns. These guys had 500+ columns by the time I reviewed it, and were looking for an investment to "scale".
Of course, it's a solvable problem, but as you can imagine everything was designed in some backwards, janky way. That was just the most obvious "wtf" moment.
> Does this sound insane to you? Obviously it should,
I dealt with the exact same thing in my 2nd ever job. Entire customer and product database (with plaintext passwords) stored in a multi-meg public-facing .js flat file that had to finish loading before the app could do anything (with early-2000s internet). And to top it off, the app was a single monolithic file, in a directory with names like index.1.js, index.final.js, index.newest.js, index.45.js, etc etc.
I had enough experience with best practices to go to our CEO and get the CTO fired, and went about rewriting it with git, mysql, and server-side logic with an actual architecture. And then, the windows server it was all running on got pwned into a porn server, and somehow it was my responsibility despite me never having seen this server and not even having admin permissions.
I heard rumor back in the late `90's of an e-commerce site that stored the prices for it's products in the browser cookie. Presumably a motivated buyer could go in and edit the cookie before checkout, although I don't know if that ever actually happened.
I worked at <large tech company everyone hates> and we had this exact architecture. The senior engineer (who went to Stanford and was proud of it) designed this system. I had long arguments with him about how this system wouldn't scale when we launched it, and used real production data to prove that it would happen. No one listened to me, it launched and imploded within a few weeks, and soon after I transferred off the team. The worst part is, that senior engineer was eventually promoted and that system was passed off to an entirely new team to battle with. That entire system was terribly designed, and I think you can guess why.
Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)
It astonished me that people can ever think this is a good idea (everything in a single json document) or that anyone who thought it was could ever get funding or even get through any basic customer due diligence.
... which while there were other red-gate posts out there, I can't find that one ever submitted as a dup to link the comments about it (this shall be rectified).
You missed the part where they say they felt like a rock star. Different people are motivated by different things. The key is, if you are very hard working try to channel it in a way that will actually benefit you.
I worked very briefly for a company (that I won't name) that did this with elasticsearch. Every customer basically had a customized form for data entry, and every field on that form became a field in ES, even if that same field name and type was on every other form in the system. Eventually they had to contract with another company to run a customized build of ES on a bespoke cluster because they blew past the default 10k limit on the number of fields in ES.
When it became clear that they had zero interest in fixing this, I tendered my resignation and quickly found a new gig with sane architectural principals.
How about reading the entire Json document out of the database, making a copy of that document, updating the copy, and saving that copy to the database...
Is how someone on my old team designed an internal tool
Is this not how you update a JSON column on a db that doesn't have (or you choose to not use for reasons) a native JSON type with a sprinkling of data should be immutable?
One team in my company insists on storing everything related to a target in an MB-size Elasticsearch document and then do all the aggregation client-side, because they already use ES for everything else and don't know how to use a relational database.
> Does this sound insane to you?
Early in my career, a client came to us with their internally developed perl web app that was very slow and asked us to help them. They were storing all of the information as csv files and would do exactly that, read the entire file, add a new row etc...
We explained to them that we should rewrite it for them :)
I don’t understand the confidence that leads to such misuse. I’m NOT a db guy by any means, and yet when I need one I’m carefully looking up things like “what’s the space complexity of compound indices”, at a development stage. Defensive and paranoid. I guess there are a lot of cowboys out there.
Most people who use an index wrong dont understand space and time tradeoffs at all, how to measure if there is a problem, or how to identify what a thing should be in the first place.
Most people who at least think a bit get pretty far before the vendor specific gotchas start biting.
Would it help, though, even in the short term? Making an actual `ticket` table really isn't that much work. If for some reason it is, you can always use an array type, or even shove JSON into a text column. Even if you're not thinking further than an MVP—hell, further than 5pm—one column=one ticket seems the most awkward and difficult solution I can think of.
> Each ticket was a column. So if your most active user had 5 tickets in total history, you needed 5 columns.
I was thinking like, "Oh yeah, they have 5 tickets, so need 5 rows. What's wrong?". And I read it again and found it's the word "column". It must be a big fun to write a query for such tables.
It would be _slightly_ better if the DBMS have array types.
Often they are not scalable, but it is better than thousands lines of copy-and-pasted code.
Honestly this is not necessarily a good reason not to invest. Sure this needs to be fixed, plus whoever allowed this to happen should be replaced but analyzing the business as an investment opportunity and passing because of this is just as insane in my opinion
Execution is what matters in startups, if they either can't find developers who are halfway decent or if a cofounder wrote this, that's a major red flag that they don't know how to execute.
Those types of design, especially the giant json document, has to be part of the reason some companies pushed pretty hard against the GDPR. Imagine trying to remove personal data from such a system.
Everything in this story is dysfunctional, including the protagonist's approach. It is completely unacceptable for a team leader to give their people time off and lie about it and he is well in to territory where the company could fire him. I wouldn't be surprised if it was a fire-for-cause situation, in fact. Although upper management sounds so off the rails that he would probably get away with it and get a commendation of some sort; it does seem to be a play to the environment he's in.
A tip for new team leads; there is nothing here to feel proud of and a better play is to kick up a huge stink about people are working overtime and insist that the vendor be held to sane standards or project scopes reconsidered to fit in a normal work week schedule. Trying to make this sort of situation work is going to burn people out for nothing, or get people fired with no potential upside.
Unless I were truly desperate for work to keep my family going, a team lead has a responsibility to protect their team's reasonable work hours from insane requests. That is a hill to get sacked over, but not to lie for.
That isn't throwing anyone under the bus. I've had literally that conversation and it went fine. If you're optimising for dev productivity, you let them take holidays and work them to a plan that lets them get a good night's sleep and some time to recover.
sometimes you burn the CTO but you better make sure you brought ample firewood because guys at top can take some serious heat before melting and most low levels underestimate the amount of firewood it takes resulting in getting roasted by the leader instead.
Once I worked for a company that had an ex-googler on the board who tried to act as CTO. Eventually I tried desperately to throw that person under the bus but the CEO bizarrely moved the bus around instead of letting the bad influence on the company take a hit.
Took a year of trying, then I left and one of the other two developers did as well. Would have stayed for longer if they payed me more which I made very clear, but they were stingy, adding like ten percent to an already pretty low salary and presenting it as such an effort on their part.
The team leader reports to the CTO. The team only reports to the team leader. Therefore, it's perfectly acceptable for the team leader to give their people the time off, and even lie about it, since it didn't affect performance.
The part you are missing here is that the work was already done and none of that progress was shared with management. After all what would they do? Accelerate the project!
Stick it to the man when they try to get others to work harder to glorify themselves. Weak bastards.
The CTO who surrounded himself with yes men and was clearly completely unaware of anything happening in the company?
The devs who were worked to the bone, but don’t worry I gave them a week off?
The protagonist who lied to everyone to hit an arbitrary date for a company that clearly doesn’t give a shit about them?
This story made me cringe at every turn. I’m a hard worker and I have put in extra hours to make a launch go smoothly for a client here and there but this story is pure insanity. I’m willing to put in the extra time on occasion because of the “relationship” I have with my boss and knowing that I can always tell them the truth. In fact that’s a core concept of having a no-blame culture, you only get that IF everyone is telling the truth.
Lying like crazy to meet a deadline for an idiot CTO is quite literally insane. If you find yourself in a situation like this then GTFO of there and find a better place to work.
> The devs who were worked to the bone, but don’t worry I gave them a week off?
Thats the part that piss me off the most. What devs get from this? Feeling of "pride and accomplishment" and burnout?
> And we hit our dates in January, went live with a great launch, and were rock stars for a bit. Maybe more like Herman’s Hermits than The Beatles. But it still felt good.
Maybe I'm lucky but I've never been fired for telling the truth and the truth is easier to align to. "There's a bug in a third party library that's part of the critical path "We can make it harder to hit the bug but can't fix it until the vendor fixes it", or "user growth has revealed performance issues no one thought we'd encounter this soon, we can spend three times as much money on infrastructure to mitigate it for the 2 months it will take is to fix it or lose customers due to performance" or "our biggest customer didn't know what they wanted until we delivered the first iteration, now they want something that isn't at all what we thought we'd be building. We can build it and be profitable or follow our dreams and die".
Again maybe I've been lucky but honesty has worked well for me.
People that surround themselves with “yes” people often fail to digest the truth. So as others have mentioned, they will “take it under advisement” and then you will slowly get phased out or put into “busy work”.
Second option is to hold your tongue, watch them struggle, and eventually fail over a long period of time. Usually 1 year but have seen it fold in less than 2-3 months and the leadership effectively canned the next quarter.
This is not really about honesty - if someone asks your opinion you can explain your concerns diplomatically - but if they don't then you can also keep quiet.
It's more about whether you're going to actively point out a problem with a plan that someone higher up than you is trying to take credit for. i.e. they will feel personally attacked - that their judgement is questioned - when you speak up.
It's an extremely difficult thing to do without making enemies and enemies last a long time and 1 enemy is more damaging than can be made up for by lots of friends.
> I dial in every morning for the mandatory death march status call with the CTO and I lie.
> “The team is working hard. Today we hit milestone integration point #73.”
> “The team made good progress yesterday, we finished another web service.”
> Every day I showed up and told the big boss that we were hard at work on stuff that we had already completed over the previous month.
I think it's a really important detail that he was lying about work that was already done. That looks like "underpromise and overdeliver" from a certain angle.
I'd feel worse about lying about work that's not done yet. Certainly riskier, and maybe not the best feeling for the team when they get back: "Here are your tickets, I told the CTO they were already done, so hurry up."
Developer interactions with management suffer from huge information imbalances, and a lack of trust.
For example, I'm working on a project now to update a code base running on a (very) old compiler. We've been working for a year, and large chunks of the system are done. One (fairly major) part is yet to be completed.
Management doesn't understand the process, or have confidence that the project will ultimately be successful. I don't blame them for being skittish, software projects (especially conversions) have a long history of failure.
We had weekly meetings with them on progress - which are now twice-weekly (because that will speed things up.) Mostly they don't attend directly, a middle manager acts as a go-between.
The developer view is that of course this will work (personally I've never been in doubt on that front) but the time-scale is uncertain because the system is large and old. But we're talking months left, not years. Yes, I'm aware of the 80/20 principle, but we're well into the 20% already.
Of course to management it's a binary state, done or not-done. It's hard for them to guage progress. There's no "trust" in what we say.
Which makes sense to me. We might have done 0 work for a year. If all we did was the meetings -they wouldn't know-.
(Its a fixed price job, so it doesn't make sense for us to drag it out.)
Of course the risk is all on them. They've spent a bunch of money and are nervous. They made (good) tech decisions (based on the advice of outside people who understand the tech) but they feel very uncertain. Ultimately if the project fails they'll take a hit (not so much us.)
There's no easy fix here - you can't just argue that managers should be technical (the tech is not their core business), and more "consultants" won't make them feel warm and fuzzy. The best we can do is push through and deliver.
>> One (fairly major) part is yet to be completed.
Break this down. Break it down into granular chunks even if they are a month long. Divide everything up into sub tasks. Even if they aren't perfect even if you have rough edges.
Name every chunk something friendly and fun. I recommend classic dances... tango, cha cha, waltz.
Call a meeting with your managers (including the high up ones). As for middle managers to start attending (auditing) daily standup. Make everyone STAND for them (so they stay short) and track against the tasks on the list in the wave.
Again, a piece being added, or a piece being late isnt going to freak any one out as long as you are close....
We both know that going live is gonna be the big hurdle just dont tell them that till your ready.
>> We both know that going live is gonna be the big hurdle just dont tell them that till your ready.
Yeah. There are over 5000 stores that this will roll out to, so it'll go slow there. Fortunately there's a dedicated (separate) testing team so thats good.
>> Break this down. Break it down into granular chunks even if they are a month long
Part of the problem is that it's not easy to break down at this point. We are aware that "it doesn't run". (There are underlying classes which affect things.) What we don't know is "how many class issues are outstanding". We knock them off, and we move to the next one. We "feel" like its close now. But any attempt at quantification is simply speculation.
We have tried -not- to introduce speculation into the process because that's not data. When we're pushed on providing speculate data (when will this be done?) we ecplain why that's impossible for us to determine and suggest (to the middle manager) that he guesses instead. He tends to not push too hard there.
Part of building trust (at least as far as him) is in not making-stuff-up. We're clear on what we do know, and clear on what we don't know.
Obviously I don't know yo what extent that is passed on upstream. Upstream are keen on dates, targets, reports on "accomplishments", all the usual management. "We don't know" is good data for them, but not what they want to hear, and perhaps not helpful to them.
> We had weekly meetings with them on progress - which are now twice-weekly (because that will speed things up.)
I've been on more than one project with delays. Delays make management nervous. I understand that, but having more meetings about it will never make things go faster.
Having a half-hour check-in with the PM every day so that they can "provide me with support and give me what I need to get the project back on track" is not helpful. There is nothing they can give me that I need other than fewer meetings. There are no obstacles but time, and the only reason that is an obstacle is because upper management insisted on an unrealistic timeline to begin with.
> They made (good) tech decisions (based on the advice of outside people who understand the tech) but they feel very uncertain.
If they took advice of internal people and then made the same internal people work on it, this trust issue might get solved.
Ultimately by showing lack of trust in their developers, they are showing lack of trust in their management skills for having selected the correct developers. They are doing one core part of their job very badly.
The problem with hiring good developers is that you need good developers and a solid corporate tech culture to hire them.
If you don't have anyone you can trust to interview technical folks, how will you avoid hiring bad developers?
And similarly, if you hire good developers but your corporate culture is bad, they'll leave, and eventually the only remaining developers will be bad ones.
It's very hard for non-tech companies to hire and retain quality talent.
Firstly because the tech team has varied enormously over the last 25 years. Some have been around a while, some are new.
Secondly because middle management (and for all I know upper management) has cycled a lot over the last 25 years. (We've had 3 different middle managers on this project in the 2.5 years since the project was first proposed.)
So, speaking generally now, it's common for the people who did the hiring not to be the ones who now have trust issues.
Equally decades of failed software projects (industry wide) have lead to a (well deserved) reputation for IT not being trustworthy.
If management has no visibility into the project progress, that seems like a pretty major problem.
It absolutely shouldn't be "binary." Any year-long project should have tractable progress metrics. Upper management doesn't need to be technical, but someone in the chain absolutely should be capable of translating progress into a digestible format.
When you build a building, it starts by digging a hole and then filling it up. Then you see walls go up etc. Although progress is visible, visible can lie.
Obviously the project had milestones. But it is in the nature of big conversions/updates that you will encounter things you don't know. We're in that stage now of killing the unknowns.
It's not a linear process and the quantity of them is unknown. So at this point metrics become hard. (We hit all the targets for the "knowns", and we continue to squash the unknowns, so the dev team is confident, but management is nervous.)
Progress is easy to digest. But (for now) there's no easy "finish line" to see, which makes their lives hard.
There's no "quick fix" here where "better paperwork" would improve things. As much as you (and indeed management) would like that.
It is a major problem, but it is the big unsolved problem of software engineering that has resisted a remarkable number of attempts by unreasonably capable people. Under normal conditions the metrics you are talking to boil down to "the dev says we're making progress". The level of formality with which they say that changes, but not the underlying process of how the metric is generated.
The only way to improve on that is for managers to go in to git and check what is happening. Technical managers can get deep into tracking progress. Non-technical managers cannot.
Readit News
I know, that, specially when you get recognised for the hard work it is hard, but you will regret every minute.
If you work for a company that counts on your holidays and vacation to sell their products, you are helping to create the problematic world with have today. If many do that, more will need to do. If none do it, and act like it is an absurd to request it (and it is) nobody is forced to do it and the company is forced to do real estimates even if that hurts your fav CEO pocket
Communicate your holiday plans, arrange coverage, put it team calendars, do hand-offs.. and then take it. Projects come & go, dates slip on their own. If you move holidays for project dates you will never take holidays.
The only exceptions would be if you are in a role with seasonality and its generally understood end of year / end of quarter / tax time / something is well known busy season and its in poor taste to disappear during it.
Even if you are a large equity partner it's at best short-sighted. I have written about this before[1] but the gist of it is that even when individual heroics saves a project it has robbed the project manager of valuable feedback regarding how the planning was deficit.
[1]: https://two-wrongs.com/hidden-cost-of-heroics.html
This is exactly how you get guilted into working during vacation; everything is sold as an exception.
Structuring your life completely around anything is a fools errand — work, video games, family, food, etc.
Unless it’s not. Maybe the only thing you care about in the world is your family and you’ll ignore everything else. Maybe video games are your truest passion and you’ll do whatever it takes to play them 80 hours a week.
Maybe I love CRUD apps and Jira as much as my next door neighbor loves his wife. Who’s to say?
If you want to devote your entire life to one thing, go nuts. It’s probably going to have some consequences whether that thing is work or not.
I have had managers say things like: "this could be the last job we ever work" as if none of us are capable of doing math.
That said we are all a bit prideful so exhausting yourself to get that fleeting feeling of having achieved something clever and good is definitely on the table.
The company had a hard deadline to move over to a brand new system. They had 5 years notice and decided not to start it until the year before. If they didn't make the deadline, it would mean millions of dollars in costs because it was outside the contract.
Him and his team made the deadline. His reward was being laid off a few weeks later as his position was eliminated. Now he's over 50 and trying to find work in a terrible time to look for a job.
The are addicted to feeling valuable and important.
When they get home from work, they have nothing else to do.
Working out frequently, getting a family, getting a side project off the ramp, and reducing to part-time have all helped me with my addiction to feeling valuable and important when nothing else is gained than becoming known for fixing stuff in weekends free of charge.
There are plenty of people like that in a company but they normally don't cluster together, so it feels like "nobody else cares". That's false. At times that's how exactly how products, or even entire companies, are saved. Because a bunch of individuals who think like that get together and work hard to accomplish something.
Whether that effort is recognized or not depends on the company. If it's not then, I agree, it would be irrational to keep pushing. But you can't know until you try.
(Edit: to be clear, I'm not advocating prioritizing work over anything else, that really depends on you, but there's a fine line between "working hard" and being obsessed. The latter will more often than not result in a net negative in most cases. The same level of effort and/or prioritization should be applied to all areas of life)
Had 1-2 childhood events that shaped you, and now you are afraid to do anything except 'be high value'.
I'm aware of it, I'm even aware of philosophies like Absurdism, good luck changing me. Its either in my DNA or faux-PTSD.
Deleted Comment
Awkward silence ensued. ...
You should put that on a coffee mug and sell it. It would make a great gift to a bunch of people that I know.
I think this is poor and dangerous advice for anyone who wants to get ahead in life. If you are happy to coast by and not achieve much in life, sure, don’t work hard. But if you want to be one of the few who either rise to the top in your field or to create value in the world, then don’t feel bad about wanting to work hard. People generally learn by doing and those who do a lot learn a lot. Of course, don’t prioritize it over things that are important to you (physical health, family etc) but don’t feel it’s wrong to prioritize it above stuff isn’t important to you (eg Netflix and YouTube shorts).
Go to therapy. Learn about yourself. Work on your communication skills. Figure out what matters to you and invest in it. (For most people, family and friends are high on that list).
By all means work hard, but be strategic about it. Martyring yourself for your company won't make people respect you.
It's worthwhile working for yourself if you do think you're learning, but in today's corporate environment loyalty is just showing your willingness to be exploited.
Shilling for work place abuse and unpaid overtime isn't getting you ahead in life the same way begging for forgivness with an abuser will make your life better.
If your corp can't manage people's time realistically, why would you expect them to manage anything realistically? Get out and go to a real place that knows how to run projects.
Work hard for yourself to build your own. But don’t think for one moment that death marches will result in a swift rise to the top.
So no, "working hard" won't get you ahead. The people who really get that far ahead in life are the ones networking and learning the political games, not really working. And why do you need to "get ahead" to be successful? I'm ambitious, and I love growing in my career. I'm not someone who is happy with the bog standard things, but I've also learned that when all you value is being ahead of your peers, you miss out on more than you gain. And on top of it, you all end up in similar roles anyway.
"rising to the top" is pure ego-inflation
"create value in the world" -- you'd better make sure that you're creating value for the world in something that's important and meaningful to you, not just "create value for shareholders" (who don't give a f about you) which is what "creating value" means 90% of the time if you're in industry
Oh yeah, every new-comer to the tech world thinks like this, and 99.99% of them don't get any further "ahead" in life than the rest of us. In fact, many end up further behind.
In a healthy company/organization:
* That outsourcing implementation approach probably wouldn't have happened, because an experienced person could've guessed how that would turn out, before it was started (it's such a cliche).
* Earlier on, people would tell the CTO it wasn't working out, instead of lying and saying the opposite.
* Whenever they needed to do something smarter/creative to rescue the project, they could work with the CTO on that, and maybe even with the customer.
* There wouldn't be marathon whip-cracking over the holidays, especially not after the team was already burning out.
* A manager/lead would go to bat for the success of the project and the health of the team, and insist upwards that the team needed a break over the holidays, if that needed to be clarified.
On that last point, in a "half-healthy" organization, a manager might intentionally be very vague, and omit information. That happens, and might or might not be a good idea, depending.
But the way this story is told, it sounds like the manager/lead outright lied repeatedly up the chain of command, which is generally considered very-bad, in both healthy and unhealthy companies.
I'll add that these things are vastly easier to armchair-quarterback. Certainly we're all going to make mistakes, especially when put in difficult positions, and/or when overextended/fatigued. But it helps to look at scenarios, to try to learn from them, and to think from a distance how they might've been handled better, so you're armed with that "experience", the next time you're tossed into a rough situation that has some similarities.
If you ever find yourself in a company like this, start looking for a new job.
It's impossible to fix rot that bad at the top, and they're not going to make you CTO.
In the short time you may save the company, in the long time you'll lose and the company will lose too.
"Because the CTO had a yearly turnover of his direct reports, every status call about the project took some variation of “great idea, boss” even though literally no one involved thought it was even a good idea. Or even a mediocre idea. It was a bad idea"
But if everyone confirms his bad decisions instead of pointing flaws out, then they are all part of the problem.
That is when I ramped up my job search to 11.
I get the impression that most large corps are of this culture at this point
This mythical beast, where can one find one? I haven't, in the past 25 years of work.
But that's ok cuz I got laid off of there, and I have no sympathy for that bumbling company. Idiots trying to outsource "solutions" that only added more pain for everyone.
Sometimes these are actual problems that need solutions but half the time ... It's just more crap to make themselves feel like they're "saving money but not building in house". Yeah just now you have to pay contracts to support the crap you never built in the first place. Good job. Golden parachutes for all the leaders, I guess.
And perhaps I've just been lucky, but in 25 years in tech I've never seen the level of gross incompetence described in this post. I'm truly envious of the vast majority of senior leaders and execs I've worked with - not because they're geniuses or anything, but because they excel at things that I find very challenging (and I know from my stint in management) and I learned a lot from them. Again, not everyone, but I've certainly had more good bosses than bad.
For starters, we can all aspire to work in a company where people wouldn't be outright lying, nor feel that they needed to.
The dark secret is that being a healthy company is just a moment, not something a company is at all times. Staying a healthy company as you grown when you are actually successful is very hard, and once the health is gone, good luck regaining it, because now you have a lot of people that thrive in unhealthy environments.
I have done this, also have brass balls and dont give a fuck. EDIT: I mean tell the truth, so rare to not hide the fuck up. See MS security memo.
> There wouldn't be marathon whip-cracking over the holidays, especially not after the team was already burning out.
Ha ha ha ha ha... Ok this is partly true. IF you work in a BANK or in a FAANG then yes. If you work in any company that has "startup culture" forget it. The thing is that skin in the game (real skin) will change your attitude about work pretty quick. I dont think there are many companies where you will get it and have the opportunity to see that.
> But the way this story is told, it sounds like the manager/lead outright lied repeatedly up the chain of command, which is generally considered very-bad, in both healthy and unhealthy companies.
Do you know how many times I have been the cowboy who got some shit done in the dark of night cause it needed to happen? Most of the people I know who are good have gone this route. Hell I have seen these sorts of things happen AT A BANK.
Bend all the rules past breaking but tell no one. As long as you aren't making a huge fiscal bet (aka more than the company or your teams value) then your gonna get away with a lot. You either do it and get promoted or you get a new job (cause you limited your ability to get promoted).
Depends what "startup culture" is.
I actually did an early startup work marathon over Christmas, to help pull off a minor miracle, and make a very hard launch date successful.
But during the same period, I also managed the tasking/planning to shield a key teammate who'd gotten sick, and take stress off of them.
> Bend all the rules past breaking but tell no one.
I think that depends on the company, and the kind of rule.
In some companies, rules tend to be there for a reason, and if you break a rule, you generally have to disclose that, and maybe discuss it (ideally beforehand).
That's the part of the story that gets me. Everyone is acts so gutless.
Some ppl just dont care coz in one year they will be in a completely different place
Does this sound insane to you? Obviously it should, but in the vein of "insane things" I was helping do tech diligence of a potential investment for a fund. The startup's users table also contained the "tickets/booking" data. Each ticket was a column. So if your most active user had 5 tickets in total history, you needed 5 columns. These guys had 500+ columns by the time I reviewed it, and were looking for an investment to "scale".
Of course, it's a solvable problem, but as you can imagine everything was designed in some backwards, janky way. That was just the most obvious "wtf" moment.
They did not get the investment.
I dealt with the exact same thing in my 2nd ever job. Entire customer and product database (with plaintext passwords) stored in a multi-meg public-facing .js flat file that had to finish loading before the app could do anything (with early-2000s internet). And to top it off, the app was a single monolithic file, in a directory with names like index.1.js, index.final.js, index.newest.js, index.45.js, etc etc.
I had enough experience with best practices to go to our CEO and get the CTO fired, and went about rewriting it with git, mysql, and server-side logic with an actual architecture. And then, the windows server it was all running on got pwned into a porn server, and somehow it was my responsibility despite me never having seen this server and not even having admin permissions.
Man, my first few jobs were educational!
It astonished me that people can ever think this is a good idea (everything in a single json document) or that anyone who thought it was could ever get funding or even get through any basic customer due diligence.
https://www.red-gate.com/simple-talk/opinion/opinion-pieces/...
... which while there were other red-gate posts out there, I can't find that one ever submitted as a dup to link the comments about it (this shall be rectified).
Schmooze the execs with fancy dinners and trips. Deliver a horrible product so they need you for the foreseeable future.
The story itself says the CTO is unaware of everything. From his perspective, everything worked out fine in the end.
Win for everyone except for the devs who put in 80 hour weeks.
When it became clear that they had zero interest in fixing this, I tendered my resignation and quickly found a new gig with sane architectural principals.
Is how someone on my old team designed an internal tool
We explained to them that we should rewrite it for them :)
Most people who at least think a bit get pretty far before the vendor specific gotchas start biting.
In a consultant project with nearly a year to deliver, no way.
I was thinking like, "Oh yeah, they have 5 tickets, so need 5 rows. What's wrong?". And I read it again and found it's the word "column". It must be a big fun to write a query for such tables.
A tip for new team leads; there is nothing here to feel proud of and a better play is to kick up a huge stink about people are working overtime and insist that the vendor be held to sane standards or project scopes reconsidered to fit in a normal work week schedule. Trying to make this sort of situation work is going to burn people out for nothing, or get people fired with no potential upside.
Unless I were truly desperate for work to keep my family going, a team lead has a responsibility to protect their team's reasonable work hours from insane requests. That is a hill to get sacked over, but not to lie for.
It is more unreasonable for the company to cancel already-given time off.
Took a year of trying, then I left and one of the other two developers did as well. Would have stayed for longer if they payed me more which I made very clear, but they were stingy, adding like ten percent to an already pretty low salary and presenting it as such an effort on their part.
Stick it to the man when they try to get others to work harder to glorify themselves. Weak bastards.
The shitty vendor who delivered crap?
The CTO who surrounded himself with yes men and was clearly completely unaware of anything happening in the company?
The devs who were worked to the bone, but don’t worry I gave them a week off?
The protagonist who lied to everyone to hit an arbitrary date for a company that clearly doesn’t give a shit about them?
This story made me cringe at every turn. I’m a hard worker and I have put in extra hours to make a launch go smoothly for a client here and there but this story is pure insanity. I’m willing to put in the extra time on occasion because of the “relationship” I have with my boss and knowing that I can always tell them the truth. In fact that’s a core concept of having a no-blame culture, you only get that IF everyone is telling the truth.
Lying like crazy to meet a deadline for an idiot CTO is quite literally insane. If you find yourself in a situation like this then GTFO of there and find a better place to work.
Thats the part that piss me off the most. What devs get from this? Feeling of "pride and accomplishment" and burnout?
> And we hit our dates in January, went live with a great launch, and were rock stars for a bit. Maybe more like Herman’s Hermits than The Beatles. But it still felt good.
Thats the part where "we" definitely means "me".
Again maybe I've been lucky but honesty has worked well for me.
Second option is to hold your tongue, watch them struggle, and eventually fail over a long period of time. Usually 1 year but have seen it fold in less than 2-3 months and the leadership effectively canned the next quarter.
It's more about whether you're going to actively point out a problem with a plan that someone higher up than you is trying to take credit for. i.e. they will feel personally attacked - that their judgement is questioned - when you speak up.
It's an extremely difficult thing to do without making enemies and enemies last a long time and 1 enemy is more damaging than can be made up for by lots of friends.
And I have been given feedback in perf reviews that I have been disagreeing too much.
And in those cases it did turn out later that I was right, so I wasn't being difficult for no reason.
> “The team is working hard. Today we hit milestone integration point #73.”
> “The team made good progress yesterday, we finished another web service.”
> Every day I showed up and told the big boss that we were hard at work on stuff that we had already completed over the previous month.
I think it's a really important detail that he was lying about work that was already done. That looks like "underpromise and overdeliver" from a certain angle.
I'd feel worse about lying about work that's not done yet. Certainly riskier, and maybe not the best feeling for the team when they get back: "Here are your tickets, I told the CTO they were already done, so hurry up."
For example, I'm working on a project now to update a code base running on a (very) old compiler. We've been working for a year, and large chunks of the system are done. One (fairly major) part is yet to be completed.
Management doesn't understand the process, or have confidence that the project will ultimately be successful. I don't blame them for being skittish, software projects (especially conversions) have a long history of failure.
We had weekly meetings with them on progress - which are now twice-weekly (because that will speed things up.) Mostly they don't attend directly, a middle manager acts as a go-between.
The developer view is that of course this will work (personally I've never been in doubt on that front) but the time-scale is uncertain because the system is large and old. But we're talking months left, not years. Yes, I'm aware of the 80/20 principle, but we're well into the 20% already.
Of course to management it's a binary state, done or not-done. It's hard for them to guage progress. There's no "trust" in what we say.
Which makes sense to me. We might have done 0 work for a year. If all we did was the meetings -they wouldn't know-. (Its a fixed price job, so it doesn't make sense for us to drag it out.)
Of course the risk is all on them. They've spent a bunch of money and are nervous. They made (good) tech decisions (based on the advice of outside people who understand the tech) but they feel very uncertain. Ultimately if the project fails they'll take a hit (not so much us.)
There's no easy fix here - you can't just argue that managers should be technical (the tech is not their core business), and more "consultants" won't make them feel warm and fuzzy. The best we can do is push through and deliver.
Break this down. Break it down into granular chunks even if they are a month long. Divide everything up into sub tasks. Even if they aren't perfect even if you have rough edges.
Name every chunk something friendly and fun. I recommend classic dances... tango, cha cha, waltz.
Call a meeting with your managers (including the high up ones). As for middle managers to start attending (auditing) daily standup. Make everyone STAND for them (so they stay short) and track against the tasks on the list in the wave.
Again, a piece being added, or a piece being late isnt going to freak any one out as long as you are close....
We both know that going live is gonna be the big hurdle just dont tell them that till your ready.
Hard to see on Teams or Slack or whatever.
Yeah. There are over 5000 stores that this will roll out to, so it'll go slow there. Fortunately there's a dedicated (separate) testing team so thats good.
>> Break this down. Break it down into granular chunks even if they are a month long
Part of the problem is that it's not easy to break down at this point. We are aware that "it doesn't run". (There are underlying classes which affect things.) What we don't know is "how many class issues are outstanding". We knock them off, and we move to the next one. We "feel" like its close now. But any attempt at quantification is simply speculation.
We have tried -not- to introduce speculation into the process because that's not data. When we're pushed on providing speculate data (when will this be done?) we ecplain why that's impossible for us to determine and suggest (to the middle manager) that he guesses instead. He tends to not push too hard there.
Part of building trust (at least as far as him) is in not making-stuff-up. We're clear on what we do know, and clear on what we don't know.
Obviously I don't know yo what extent that is passed on upstream. Upstream are keen on dates, targets, reports on "accomplishments", all the usual management. "We don't know" is good data for them, but not what they want to hear, and perhaps not helpful to them.
I've been on more than one project with delays. Delays make management nervous. I understand that, but having more meetings about it will never make things go faster.
Having a half-hour check-in with the PM every day so that they can "provide me with support and give me what I need to get the project back on track" is not helpful. There is nothing they can give me that I need other than fewer meetings. There are no obstacles but time, and the only reason that is an obstacle is because upper management insisted on an unrealistic timeline to begin with.
If they took advice of internal people and then made the same internal people work on it, this trust issue might get solved.
Ultimately by showing lack of trust in their developers, they are showing lack of trust in their management skills for having selected the correct developers. They are doing one core part of their job very badly.
If you don't have anyone you can trust to interview technical folks, how will you avoid hiring bad developers?
And similarly, if you hire good developers but your corporate culture is bad, they'll leave, and eventually the only remaining developers will be bad ones.
It's very hard for non-tech companies to hire and retain quality talent.
Firstly because the tech team has varied enormously over the last 25 years. Some have been around a while, some are new.
Secondly because middle management (and for all I know upper management) has cycled a lot over the last 25 years. (We've had 3 different middle managers on this project in the 2.5 years since the project was first proposed.)
So, speaking generally now, it's common for the people who did the hiring not to be the ones who now have trust issues.
Equally decades of failed software projects (industry wide) have lead to a (well deserved) reputation for IT not being trustworthy.
It absolutely shouldn't be "binary." Any year-long project should have tractable progress metrics. Upper management doesn't need to be technical, but someone in the chain absolutely should be capable of translating progress into a digestible format.
Obviously the project had milestones. But it is in the nature of big conversions/updates that you will encounter things you don't know. We're in that stage now of killing the unknowns.
It's not a linear process and the quantity of them is unknown. So at this point metrics become hard. (We hit all the targets for the "knowns", and we continue to squash the unknowns, so the dev team is confident, but management is nervous.)
Progress is easy to digest. But (for now) there's no easy "finish line" to see, which makes their lives hard.
There's no "quick fix" here where "better paperwork" would improve things. As much as you (and indeed management) would like that.
The only way to improve on that is for managers to go in to git and check what is happening. Technical managers can get deep into tracking progress. Non-technical managers cannot.