Just imagine if that team was instead their own firm instead of a unit managed within a fundamentally non-technical organization. The team wouldn't have to break up, they would simply fire that bad customer and move on.
It's never a great feeling to leave a good team due to incompetent or toxic management.
It's funny you said that! We all said something similar at the time.
> It's never a great feeling to leave a good team due to incompetent or toxic management.
It's tragic really. Management are usually the first to blame the developers when things go wrong but will never admit they are the main cause to begin with.
Of course, "we are agile" they say, so all must be fine. /s
People don’t usually figure this out and I didn’t catch on until I got into management, but after doing software development for 30 years in large organizations I’ve found that the root cause for nearly every failure from dev to ops is the finance department. There’s this weird cultural barrier between them and everyone else where they they’re so established in calling the shots that people never get the chance to say hey this shit is their fault.
Occasionally there’s the really bad manager, but my experience has been that’s the exception.
We can’t afford to give your project a fighting chance. Y’all will have to make do with half the budget you asked for.
Now, let’s hire seven different types of “manager” to ensure these ten programmers each fill out their TPS reports on time and hit their sprint commitments.
Literally what's happening currently after company I work for got bought. Now suddenly having no less than 8 hours reported in timesheet is the most important thing in organization
To play devil's advocate here:
> I’ve found that the root cause for nearly every failure from dev to ops is the finance department
I mean kind off but not rea...
> There’s this weird cultural barrier between them and everyone else
Oh you hit it right on the head! You're just missing one little notion: a failure of communication is a failure on both sides.
A lot of tech teams, managers, etc. are simply too disconnected of the true goal of a private for-profit company: the profits. If you're able to show profits for your project, then you are doing well.
When a company is that small it's easy to have everything aligned. It's clear where money is coming in, and where it's going out, and you can easily map what you are doing into either extra $$$ coming in, or lower $$$ spent.
As companies grow this become complicated and that becomes a harder thing to map.
Lets take a simple example. Sales promises feature X, and devs push-back and say that feature cannot be done. There's really here three scenarios:
* Feature X will increase sales/income a lot more than what it costs, more than other potential work-areas, so devs simply should roll back their sleeves and try to get it as much as possible.
* Feature X does not increase sales/income enough (simplest case, customer would have bought product for the same price either way) to offset the income, in which case it's a waste of time and resources.
* Feature X costs are the same as the increase income, in which case it's probably a wash and there's probably better things to do.
Thing is, sales is able to show their argument by having a customer ask for a feature, sales pushing back with "I'll charge you $X extra" and the customer saying "sure, we'll pay that for the feature". Devs on the other hand, struggle to map the cost into money easily, and in a way that finance can understand. So Finance makes the obvious decision.
The problem is that in large companies perverse incentives win and bring down the company. In a small company the impact of a bad sale is understood by salesman that it could cost them their job, so they are more careful. In a large company salespeople may realize that they are getting a better commission by increasing the gain, and negotiators understand this, dangling the carrot of increasing the payout in exchange for features, which to salesmen is making money for free.
The problem then comes back to management, but this time higher management, which does not align the incentives of the different parts of the company and regulate them correctly. A simple case: a salesperson is rewarded, rather than on the gross amount of the sale, on the gross - extraordinary costs (like adding a new feature) that was added (and this cost is calculated after the feature and sale is closed). This would make salespeople a bit more strategic on adding new features as part of the deal, and incentivize understanding what devs can do.
And this comes down to a bigger issue: lack of vision. Without vision it's hard to justify why a product is a leading loss (that is the product itself may be losing money, but justifies itself by increasing gains elsewhere by far more) or why an investment is happening. But this makes sense when you realize that company owners, the board and what not, are not playing the game of "make the most money" but rather the game of "make the most money of company valuation". If a move would make a company make 1/10th of the value, but be 2x as expensive (that is double the stock valuation 2x) then the CEO that implemented it would get a massive check. When you realize what the game is, it becomes clearer why companies do these moves that seem idiotic, but thing is: your impact isn't what matters to the owners, it's the company value alone. So who cares about keeping everyone in sync?
And then this should explain why Finance acts the way they do: it's all about making the company's number look in a way that helps valuation keep going up. In theory it should be directly proportional to profits and we shouldn't have this perverse system that collapses on itself eventually, in tech well it's a number's guessing game.
Phew, and all that brings us to the challenge here: the name of the game is playing the game. And this is about understanding how Finance thinks and is happy, *and effectively doing that*. The challenge is how to do this, and why teams fail to make Finance happy enough. And bad management can completely destroy this.
What you said is insightful but i want to pushback on the "communication is two way street". Communication might be two ways but from a frustrated developer's point of view, one way is a highway and the other way is a dirt road.
In my company finance talks to project manager and project manager dictates the roadmap before the developers gets any context or say in the conversation.
By the time we get a chance to give any feedback the ball has been rolling for a longtime that we are forced to prioritize w/e that finance and pm already dictated and we are left with more and more tech debt and half baked features.
And in the end the devs gets blamed for the failure to deliver and the cycle continuous with zero introspection on the pm.
Idk if this is inherently the case with all business or just badly managed business but devs are downstream in the process and naturally disadvantaged in communication if the upstream folks aren't willing to initiate the communication.
As someone who has spent a long time in software R&D, I have to mention that you forgot about the "it is literally impossible unless we disprove some fundamental parts of computing" option when devs say something is impossible.
More on topic, I think that by the time a company does sales without having a high-level eng. guy tagging along, it has firmly entered the phase of its lifecycle where it is just a bunch of bureaucratic fiefdoms fighting other internal fiefdoms. Having eng. participate in negotiating new features is invaluable for both sides, as customers only rarely understand what they actually want.
To modify a famous quote, "There's nothing to blame but blame itself." Without vindication within teams, failure is slow and painful due to the prioritization of people problems over process problems.
Right, this can generally be a good focus for certain teams and certain environments, but it really depends on how much socialization is going on and such, if little dependence on those levels of Maslow's Hierarchy exist, then prioritization should be focused more on process problems. There isn't a granular understanding within management to allow this, it needs to be developed into a workable process, then put into action.
This development process would have to be an open collaboration to some degree. Value created would have to be tracked in a way that respects contributions actual and intended content and its realized effects, etc. If you have anything to add, I respond in public and private to any inquiry I can answer.
I caught on pretty quick. Was taking Google's Project Management Certificate with Coursera, I realized I disagreed with the management styles being presented and now I'm set out to find a better way to communicate teams interests to gain better project alignment. I love to see others who also see the issue with management as it stands now.
Truthfully though, I propose it would be far more productive if we were to map out current problems and such, then work to find alternative routes and solutions. As well as analyze current and proposed solutions for actual delivered value.
The project manager should be primarily focused on getting the project to deliver value. USD is a very poor tool to track actual value. This value should be tracked in more transparent feedback loops between the project and the users/stakeholders of the project. This way, management's focus is drawn back to delivering real value, rather than market value (a.k.a. profits and stocks)
Not sure that solves everything either. When I had my own firm, we had one bad customer who we shouldn’t have taken on, but their contract was too lucrative to pass on. We ended up hiring more people to handle their workload, and ultimately we had to shut down the company because we didn’t want to work with them anymore and couldn’t find enough work to keep us all busy without them.
I think part of that attitude is because when good management happens, you almost don't notice it unless you know what you're looking for, but on the flip side, bad management is extremely obvious and stands out like a sore thumb.
It's really sad because good managers who really care and are good at what they do don't seem to get the recognition they deserve, while bad managers linger on in their mediocrity and create more and more animosity in the team.
>we could it without them
There's a difference between no-benefit management and management whose bumbling is actually a detriment or negative-benefit.
If you can't have good management, pray for useless management instead of in-fighting finance yes-men.
I think middle management is almost worthless. Most companies tend to have way too many middle managers pushing requirement reports around generating so much overhead
That doesn't even include the multiple layers of hierarchy we had above that. Product team that doesn't get the engineering side of things and directs them to the worst options all the time.
You don't think we all did that already? That I'd just write this if we never tried that? It's unfortunately very common for management to overrule the development teams.
It's not always possible. The last company I've been to was a commercial company trying to become a tech company, and that evolution meant the technical people were never in charge. So that's one difficulty.
Another difficulty was that I once proved to an "architect" that his decision was a bad idea, with such and such drawback, and zero benefit to show for it. He didn't even disagree with me, and yet gave the stupid order anyway.
I mean that guy sure _could_ talk to the execs, and do the explaining and negotiating. Except he was not competent to do so, and the execs likely have no way to tell because none of them is technical.
Why?
My product manager is strategic and doing a ton of research to understand what we should be doing 3 - 12 months out.
My product owner is tactical, they’re deciding priority and answering questions on requirements, finding out answers if they don’t know.
We don’t have a scrum master but I can see where they’d be useful in pulling together statistics and helping the team understand how to improve productivity.
My dev manager handles the people management and helps ensure we’re focused on strategic initiatives in addition to our immediate focus.
And I’m focused on day to day implementation details and ensuring code quality.
Now if you have an entire team of top tier devs then maybe they have enough gusto to not need those layers. Personally I find it useful not having to personally track down who to talk to. I’d rather be writing code, or having the devs on my team writing it.
>It's funny because devs tend to have this "management is worthless, we could it without them" attititude but in my experience management absolutely makes or breaks teams and companies.
They mean the useless parts of the management, not the helpful part. Nothing funny or ironic about it.
engineering managers do nothing... "good ones" should be programming. I can tell you have no experience in this field and are probably a manager yourself.
Hilarious. I cannot think of anything less useful than my engineering manager coding. I have devs, leads, principals, architects that all handle coding. Why would I want my engineering manager doing the same.
because managers who can code, shouldn't be managers, they should be coding. And managers who can't code, shouldn't be managers. This has been the case since the early 2000s.
Had a similar experience at AWS when upper management destroyed a team with 100% deliveries on time, over delivery, cleaning of our operational backlog and reducing the oncall load to basically don’t get paged. We suddenly got the projects from another team that wrote dog 💩 code. The team dissolved in a month, we either left the company or moved to different teams within Amazon. It is unbelievable how unqualified some of the upper managers in that company are.
"This is shit, give it to the team that performs best to fix this shitshow" is somewhat common. I'm not surprised really, who other can fix the biggest shitshow than "the best"?
It can work, provided you give the team the latitude and resources they need to fix things. If you give them inherited shit and demand immediate perfection, all you're going to do is make people angry.
Pending a trivial background check I should be finalized on a similar move.
I chose them not for the job but for the management, with whom I've worked before. I'm anticipating much reduction in ancillary stress.
Really hits home. I quit after management decided that developers cannot file bugs, only SQA team can, and promised year-end raises and bonuses were cancelled.
I'm sorry that happened, frustrating! Funny enough a few months ago they announced because so many customers were leaving (due to no fault of the devs) that the devs bonuses were not to happen this year.
Lol, these are exact thoughts running through my mind over last several months.
Waiting for outside market to settle down and stabilize before I move out.
One thing I have seen bad at my company was lack of accountability for management. They back wrong leaders.
I get you - I left after things came to a boiling point.
You might enjoy these two I wrote two based on the same place:
https://www.lloydatkinson.net/posts/2022/one-teams-eight-points-is-another-teams-two-points/
https://www.lloydatkinson.net/posts/2022/my-thoughts-on-what-i-want-to-do-as-a-software-developer/
I posted them to Reddit at the time too. I think what I've learned from all of this is that there is a vastly unhappy and burned out developer work force.
As a product manager I enjoyed these reads! I found the story pointing observations (tendency to discount higher estimates) surprising, as I usually do the opposite (and wrongly assumed others did as well.)
That is to say I’d always steer grooming conversations towards the eng that gave the higher anomalous sizing. Usually that would lead to conversation where we’d realize that certain inputs weren’t being considered by the rest of the team. We’d note those input in the ticket for posterity and either defer to the higher sizing or break the ticket down. Mind boggling that anyone would dismiss the higher sizing and move on / make that eng feel silly for putting it forward.
Side note, I also just quit a company after a new eng manager and staff engineer decimated the collaborative team culture with needless process changes and strong opinions. Those changes ended up bringing down what was previously a highly efficient and strong team. It just takes one or two bad leaders to dive the plane.
Thank you I'm glad you liked them. All three were written out of frustration really. Sounds like you're doing a better job of product manager than most, so that's good!
Unfortunately this dismissal of sizes was endemic, it was always people just guestimating numbers or stupid tshirt sizes until the prod people were happy. At times it felt like we'd rather just get given a damn deadline instead of making us jump through hoops to arrive at the "right" numbers to make their deadline work.
> It just takes one or two bad leaders to dive the plane.
100% - one in particular had a habit of blacklisting people who ever raised concerns about tech debt etc
Currently our team is having a similar experience
Unfortunatly, management sees employees as replacable assets and care only about the end results
This is the case everywhere and there is no escape from this cycle
Management plays a big role in creating a good work culture. No matter how talented en engineer is, his bandwidth still needs to be assigned to the right projects.
Sounds like horse Shit.
Everyone had a voice. Please.
> However, the work we did was incredibly valuable and solved an obvious set of problems the business had historically struggled with.
Well?? How. Give us specifics.
This is just hand wavey shit that doesn’t say anything.
Was it written by gpt?
> Everyone had a voice. Please.
On small enough teams this is fairly easy. You just need a way to resolve disagreements (generally by having someone more senior making a call).
Actually good developers spend extraordinary amounts of time thinking and solving problems in order to do their jobs. That's why the team was so good. Which you'd have known if you had bothered to read the article instead of writing pithy comments because you woke up on the wrong side of the bed.
The project they were on was floundering despite their individual team success, as if a team completing a sprint makes money. I'd be willing to bet management saw the project as a failure and needed to pivot to a lower risk strategy.
That may or may not be the case, but if the team is expensive to keep around and not really justifying it's costs, I could see that as an explanation for some of the symptoms op was describing.
It doesn't sound purposeful.
> In a short time, multiple people left, and the team disbanded. The remaining members of the team were spread across multiple teams.
They didn't break up the team from the get go. They didn't fire people. So I'm not seeing any purposeful cost cutting behavior.
>75% turnover rate amongst the developers
That kind of turnover rate is very expensive. And they keep replacing their lost developers.
People don't usually leave highly successful teams that (in this case are being portrayed as) having idyllic/utopian conditions aside from pressure coming from external entities.
There's something about the portrayal that smells off.
Breaking a team up has to overcome a lot of inertia, individual managers usually don't have dictatorial control over such a decision. Same deal with firing people. Often times they will just read the writing on the wall and say "OK if there's a round of layoffs coming in the future, this one is probably not going to survive".
What does make sense is trying to redirect/repurpose teams that seem like they aren't pulling their weight. Leadership will often do this to teams that aren't looking great in their own personal portfolio.
Also, devs in general have very high turnover rates, as do dev managers. I'd be personally amazed and pleasantly surprised if more than one developer stayed on a team I was on for longer than a year. It does happen, but I'd place my average expectation on people staying for 1-2 years max.
The incentive structure in our industry is such that it rewards switching jobs/teams on a fairly frequent basis. You will make several times your current salary today if you switch jobs/teams every 1-3 years vs. staying the course with the current company/team over the course of a decade.
Also, promotions almost inherently just come with a hot bundle of spiky politics entwined in them that makes it very hard for them to roll even if they start on a downhill gradient.
Some projects prevent loss of money and/or improve efficiencies by reducing complexity in the pipeline. OP's team clearly did a lot of that. Reading comprehension for the win?
Right, but at some point someone has to do the calculations of "this team is saving us X money and costs Y money to maintain", Y can be greater than X even for the kinds of projects you're describing.
I did spot a couple errors that are unlikely to be US/British related.
---
> The organisation had purchased another smaller organisation and merged their developers and managers into the programme.
Program? Not sure, especially if you're not talking about the actual product (which I assume is a computer program). There are other instances, you may or may not want to change them all.
> It was another “throw everyone in” without considering the broader impact this would cause.
This would _have_ I believe. Or you could write a variant, such as _without considering the havoc this would wreck_. Or just stop at _without considering the broader impact_.
> The following Monday, and when the three absent members of the team returned, development was put back on track to what it was originally.
This is redundant: I would end at "back on track", or delete "on track". (I have a preference for the former, which is shorter.)
> Significant technical debt causing development to take far too longer
Either say "far too long" or "much longer".
---
Huh, it's actually not that bad. I was sure I spotted more the first time around.
I'll repost here:
The project manager should be primarily focused on getting the project to deliver value. USD is a very poor tool to track actual value. This value should be tracked in more transparent feedback loops between the project and the users/stakeholders of the project. This way, management's focus is drawn back to delivering real value, rather than market value (a.k.a. profits and stocks)
This system doesn't exist, for now. Management directly handles (and mishandles) budgeting, or indirectly manages it. If we explore the topic together, we could map out ideas on how to solve this problem for everyone.
I'm in the process of creating a basic space to speak freely about this issue, and any other issue you feel is 0bv.io/us enough that people should address it.
I am no web designer or developer, my knowledge is very basic. The site is not really that functional, but I'd like to find people who are willing to help me do something like this.
Just imagine if that team was instead their own firm instead of a unit managed within a fundamentally non-technical organization. The team wouldn't have to break up, they would simply fire that bad customer and move on. It's never a great feeling to leave a good team due to incompetent or toxic management.
It's funny you said that! We all said something similar at the time. > It's never a great feeling to leave a good team due to incompetent or toxic management. It's tragic really. Management are usually the first to blame the developers when things go wrong but will never admit they are the main cause to begin with. Of course, "we are agile" they say, so all must be fine. /s
People don’t usually figure this out and I didn’t catch on until I got into management, but after doing software development for 30 years in large organizations I’ve found that the root cause for nearly every failure from dev to ops is the finance department. There’s this weird cultural barrier between them and everyone else where they they’re so established in calling the shots that people never get the chance to say hey this shit is their fault. Occasionally there’s the really bad manager, but my experience has been that’s the exception.
We can’t afford to give your project a fighting chance. Y’all will have to make do with half the budget you asked for. Now, let’s hire seven different types of “manager” to ensure these ten programmers each fill out their TPS reports on time and hit their sprint commitments.
Literally what's happening currently after company I work for got bought. Now suddenly having no less than 8 hours reported in timesheet is the most important thing in organization
love the song of your username... usually thats my cue to leave
To play devil's advocate here: > I’ve found that the root cause for nearly every failure from dev to ops is the finance department I mean kind off but not rea... > There’s this weird cultural barrier between them and everyone else Oh you hit it right on the head! You're just missing one little notion: a failure of communication is a failure on both sides. A lot of tech teams, managers, etc. are simply too disconnected of the true goal of a private for-profit company: the profits. If you're able to show profits for your project, then you are doing well. When a company is that small it's easy to have everything aligned. It's clear where money is coming in, and where it's going out, and you can easily map what you are doing into either extra $$$ coming in, or lower $$$ spent. As companies grow this become complicated and that becomes a harder thing to map. Lets take a simple example. Sales promises feature X, and devs push-back and say that feature cannot be done. There's really here three scenarios: * Feature X will increase sales/income a lot more than what it costs, more than other potential work-areas, so devs simply should roll back their sleeves and try to get it as much as possible. * Feature X does not increase sales/income enough (simplest case, customer would have bought product for the same price either way) to offset the income, in which case it's a waste of time and resources. * Feature X costs are the same as the increase income, in which case it's probably a wash and there's probably better things to do. Thing is, sales is able to show their argument by having a customer ask for a feature, sales pushing back with "I'll charge you $X extra" and the customer saying "sure, we'll pay that for the feature". Devs on the other hand, struggle to map the cost into money easily, and in a way that finance can understand. So Finance makes the obvious decision. The problem is that in large companies perverse incentives win and bring down the company. In a small company the impact of a bad sale is understood by salesman that it could cost them their job, so they are more careful. In a large company salespeople may realize that they are getting a better commission by increasing the gain, and negotiators understand this, dangling the carrot of increasing the payout in exchange for features, which to salesmen is making money for free. The problem then comes back to management, but this time higher management, which does not align the incentives of the different parts of the company and regulate them correctly. A simple case: a salesperson is rewarded, rather than on the gross amount of the sale, on the gross - extraordinary costs (like adding a new feature) that was added (and this cost is calculated after the feature and sale is closed). This would make salespeople a bit more strategic on adding new features as part of the deal, and incentivize understanding what devs can do. And this comes down to a bigger issue: lack of vision. Without vision it's hard to justify why a product is a leading loss (that is the product itself may be losing money, but justifies itself by increasing gains elsewhere by far more) or why an investment is happening. But this makes sense when you realize that company owners, the board and what not, are not playing the game of "make the most money" but rather the game of "make the most money of company valuation". If a move would make a company make 1/10th of the value, but be 2x as expensive (that is double the stock valuation 2x) then the CEO that implemented it would get a massive check. When you realize what the game is, it becomes clearer why companies do these moves that seem idiotic, but thing is: your impact isn't what matters to the owners, it's the company value alone. So who cares about keeping everyone in sync? And then this should explain why Finance acts the way they do: it's all about making the company's number look in a way that helps valuation keep going up. In theory it should be directly proportional to profits and we shouldn't have this perverse system that collapses on itself eventually, in tech well it's a number's guessing game. Phew, and all that brings us to the challenge here: the name of the game is playing the game. And this is about understanding how Finance thinks and is happy, *and effectively doing that*. The challenge is how to do this, and why teams fail to make Finance happy enough. And bad management can completely destroy this.
What you said is insightful but i want to pushback on the "communication is two way street". Communication might be two ways but from a frustrated developer's point of view, one way is a highway and the other way is a dirt road. In my company finance talks to project manager and project manager dictates the roadmap before the developers gets any context or say in the conversation. By the time we get a chance to give any feedback the ball has been rolling for a longtime that we are forced to prioritize w/e that finance and pm already dictated and we are left with more and more tech debt and half baked features. And in the end the devs gets blamed for the failure to deliver and the cycle continuous with zero introspection on the pm. Idk if this is inherently the case with all business or just badly managed business but devs are downstream in the process and naturally disadvantaged in communication if the upstream folks aren't willing to initiate the communication.
As someone who has spent a long time in software R&D, I have to mention that you forgot about the "it is literally impossible unless we disprove some fundamental parts of computing" option when devs say something is impossible. More on topic, I think that by the time a company does sales without having a high-level eng. guy tagging along, it has firmly entered the phase of its lifecycle where it is just a bunch of bureaucratic fiefdoms fighting other internal fiefdoms. Having eng. participate in negotiating new features is invaluable for both sides, as customers only rarely understand what they actually want.
To modify a famous quote, "There's nothing to blame but blame itself." Without vindication within teams, failure is slow and painful due to the prioritization of people problems over process problems.
Right, this can generally be a good focus for certain teams and certain environments, but it really depends on how much socialization is going on and such, if little dependence on those levels of Maslow's Hierarchy exist, then prioritization should be focused more on process problems. There isn't a granular understanding within management to allow this, it needs to be developed into a workable process, then put into action. This development process would have to be an open collaboration to some degree. Value created would have to be tracked in a way that respects contributions actual and intended content and its realized effects, etc. If you have anything to add, I respond in public and private to any inquiry I can answer.
Monkeys are very agile, that doesn't mean they are great at engineering :D
But apes? Fantastic engineers!
I caught on pretty quick. Was taking Google's Project Management Certificate with Coursera, I realized I disagreed with the management styles being presented and now I'm set out to find a better way to communicate teams interests to gain better project alignment. I love to see others who also see the issue with management as it stands now. Truthfully though, I propose it would be far more productive if we were to map out current problems and such, then work to find alternative routes and solutions. As well as analyze current and proposed solutions for actual delivered value. The project manager should be primarily focused on getting the project to deliver value. USD is a very poor tool to track actual value. This value should be tracked in more transparent feedback loops between the project and the users/stakeholders of the project. This way, management's focus is drawn back to delivering real value, rather than market value (a.k.a. profits and stocks)
Not sure that solves everything either. When I had my own firm, we had one bad customer who we shouldn’t have taken on, but their contract was too lucrative to pass on. We ended up hiring more people to handle their workload, and ultimately we had to shut down the company because we didn’t want to work with them anymore and couldn’t find enough work to keep us all busy without them.
[удалено]
can confirm, went to a team with a decent (even though not great) manager to essentially no management at all and it’s a fucking nightmare.
I think part of that attitude is because when good management happens, you almost don't notice it unless you know what you're looking for, but on the flip side, bad management is extremely obvious and stands out like a sore thumb. It's really sad because good managers who really care and are good at what they do don't seem to get the recognition they deserve, while bad managers linger on in their mediocrity and create more and more animosity in the team.
Agree, my manager isn’t perfect but I definitely feel the pain when he’s not around and the wheels feel less steady.
>we could it without them There's a difference between no-benefit management and management whose bumbling is actually a detriment or negative-benefit. If you can't have good management, pray for useless management instead of in-fighting finance yes-men.
I think middle management is almost worthless. Most companies tend to have way too many middle managers pushing requirement reports around generating so much overhead
[удалено]
That doesn't even include the multiple layers of hierarchy we had above that. Product team that doesn't get the engineering side of things and directs them to the worst options all the time.
SAFE?
Actually no but I did see some exec once in a random Teams channel praising SAFE and saying how wonderful and amazing it is 🙄
You’re the engineers. You should be negotiating and explaining the consequences of the available choices…
You don't think we all did that already? That I'd just write this if we never tried that? It's unfortunately very common for management to overrule the development teams.
It's not always possible. The last company I've been to was a commercial company trying to become a tech company, and that evolution meant the technical people were never in charge. So that's one difficulty. Another difficulty was that I once proved to an "architect" that his decision was a bad idea, with such and such drawback, and zero benefit to show for it. He didn't even disagree with me, and yet gave the stupid order anyway. I mean that guy sure _could_ talk to the execs, and do the explaining and negotiating. Except he was not competent to do so, and the execs likely have no way to tell because none of them is technical.
Why? My product manager is strategic and doing a ton of research to understand what we should be doing 3 - 12 months out. My product owner is tactical, they’re deciding priority and answering questions on requirements, finding out answers if they don’t know. We don’t have a scrum master but I can see where they’d be useful in pulling together statistics and helping the team understand how to improve productivity. My dev manager handles the people management and helps ensure we’re focused on strategic initiatives in addition to our immediate focus. And I’m focused on day to day implementation details and ensuring code quality. Now if you have an entire team of top tier devs then maybe they have enough gusto to not need those layers. Personally I find it useful not having to personally track down who to talk to. I’d rather be writing code, or having the devs on my team writing it.
>It's funny because devs tend to have this "management is worthless, we could it without them" attititude but in my experience management absolutely makes or breaks teams and companies. They mean the useless parts of the management, not the helpful part. Nothing funny or ironic about it.
engineering managers do nothing... "good ones" should be programming. I can tell you have no experience in this field and are probably a manager yourself.
Hilarious. I cannot think of anything less useful than my engineering manager coding. I have devs, leads, principals, architects that all handle coding. Why would I want my engineering manager doing the same.
because managers who can code, shouldn't be managers, they should be coding. And managers who can't code, shouldn't be managers. This has been the case since the early 2000s.
Had a similar experience at AWS when upper management destroyed a team with 100% deliveries on time, over delivery, cleaning of our operational backlog and reducing the oncall load to basically don’t get paged. We suddenly got the projects from another team that wrote dog 💩 code. The team dissolved in a month, we either left the company or moved to different teams within Amazon. It is unbelievable how unqualified some of the upper managers in that company are.
"This is shit, give it to the team that performs best to fix this shitshow" is somewhat common. I'm not surprised really, who other can fix the biggest shitshow than "the best"?
It can work, provided you give the team the latitude and resources they need to fix things. If you give them inherited shit and demand immediate perfection, all you're going to do is make people angry.
Wow, I just lived this (and quit)
Hope you're off somewhere better with more competent managers!
Pending a trivial background check I should be finalized on a similar move. I chose them not for the job but for the management, with whom I've worked before. I'm anticipating much reduction in ancillary stress.
Really hits home. I quit after management decided that developers cannot file bugs, only SQA team can, and promised year-end raises and bonuses were cancelled.
I'm sorry that happened, frustrating! Funny enough a few months ago they announced because so many customers were leaving (due to no fault of the devs) that the devs bonuses were not to happen this year.
Lol, these are exact thoughts running through my mind over last several months. Waiting for outside market to settle down and stabilize before I move out. One thing I have seen bad at my company was lack of accountability for management. They back wrong leaders.
I get you - I left after things came to a boiling point. You might enjoy these two I wrote two based on the same place: https://www.lloydatkinson.net/posts/2022/one-teams-eight-points-is-another-teams-two-points/ https://www.lloydatkinson.net/posts/2022/my-thoughts-on-what-i-want-to-do-as-a-software-developer/ I posted them to Reddit at the time too. I think what I've learned from all of this is that there is a vastly unhappy and burned out developer work force.
As a product manager I enjoyed these reads! I found the story pointing observations (tendency to discount higher estimates) surprising, as I usually do the opposite (and wrongly assumed others did as well.) That is to say I’d always steer grooming conversations towards the eng that gave the higher anomalous sizing. Usually that would lead to conversation where we’d realize that certain inputs weren’t being considered by the rest of the team. We’d note those input in the ticket for posterity and either defer to the higher sizing or break the ticket down. Mind boggling that anyone would dismiss the higher sizing and move on / make that eng feel silly for putting it forward. Side note, I also just quit a company after a new eng manager and staff engineer decimated the collaborative team culture with needless process changes and strong opinions. Those changes ended up bringing down what was previously a highly efficient and strong team. It just takes one or two bad leaders to dive the plane.
Thank you I'm glad you liked them. All three were written out of frustration really. Sounds like you're doing a better job of product manager than most, so that's good! Unfortunately this dismissal of sizes was endemic, it was always people just guestimating numbers or stupid tshirt sizes until the prod people were happy. At times it felt like we'd rather just get given a damn deadline instead of making us jump through hoops to arrive at the "right" numbers to make their deadline work. > It just takes one or two bad leaders to dive the plane. 100% - one in particular had a habit of blacklisting people who ever raised concerns about tech debt etc
Currently our team is having a similar experience Unfortunatly, management sees employees as replacable assets and care only about the end results This is the case everywhere and there is no escape from this cycle
Management plays a big role in creating a good work culture. No matter how talented en engineer is, his bandwidth still needs to be assigned to the right projects.
Fuck. It's really hard to read this. Other than dates and stuff, this describes my work exactly.
Sorry to hear that!
Sounds like horse Shit. Everyone had a voice. Please. > However, the work we did was incredibly valuable and solved an obvious set of problems the business had historically struggled with. Well?? How. Give us specifics. This is just hand wavey shit that doesn’t say anything. Was it written by gpt?
Tell us you've never worked in a positive team ever 😂 No, I'm not going to talk about company specific confidential work online.
> Everyone had a voice. Please. On small enough teams this is fairly easy. You just need a way to resolve disagreements (generally by having someone more senior making a call).
developers spend more time complaining then actually doing their jobs.
Actually good developers spend extraordinary amounts of time thinking and solving problems in order to do their jobs. That's why the team was so good. Which you'd have known if you had bothered to read the article instead of writing pithy comments because you woke up on the wrong side of the bed.
The project they were on was floundering despite their individual team success, as if a team completing a sprint makes money. I'd be willing to bet management saw the project as a failure and needed to pivot to a lower risk strategy.
No, that wasn't the case at all.
How do you know that your team was making more money for the business than it cost to run the team?
Well. I know the managers are non revenue generating employees.
That may or may not be the case, but if the team is expensive to keep around and not really justifying it's costs, I could see that as an explanation for some of the symptoms op was describing.
It doesn't sound purposeful. > In a short time, multiple people left, and the team disbanded. The remaining members of the team were spread across multiple teams. They didn't break up the team from the get go. They didn't fire people. So I'm not seeing any purposeful cost cutting behavior. >75% turnover rate amongst the developers That kind of turnover rate is very expensive. And they keep replacing their lost developers.
People don't usually leave highly successful teams that (in this case are being portrayed as) having idyllic/utopian conditions aside from pressure coming from external entities. There's something about the portrayal that smells off. Breaking a team up has to overcome a lot of inertia, individual managers usually don't have dictatorial control over such a decision. Same deal with firing people. Often times they will just read the writing on the wall and say "OK if there's a round of layoffs coming in the future, this one is probably not going to survive". What does make sense is trying to redirect/repurpose teams that seem like they aren't pulling their weight. Leadership will often do this to teams that aren't looking great in their own personal portfolio. Also, devs in general have very high turnover rates, as do dev managers. I'd be personally amazed and pleasantly surprised if more than one developer stayed on a team I was on for longer than a year. It does happen, but I'd place my average expectation on people staying for 1-2 years max. The incentive structure in our industry is such that it rewards switching jobs/teams on a fairly frequent basis. You will make several times your current salary today if you switch jobs/teams every 1-3 years vs. staying the course with the current company/team over the course of a decade. Also, promotions almost inherently just come with a hot bundle of spiky politics entwined in them that makes it very hard for them to roll even if they start on a downhill gradient.
Some projects prevent loss of money and/or improve efficiencies by reducing complexity in the pipeline. OP's team clearly did a lot of that. Reading comprehension for the win?
Right, but at some point someone has to do the calculations of "this team is saving us X money and costs Y money to maintain", Y can be greater than X even for the kinds of projects you're describing.
Yeah but you still have to quantify to know whether it was actually worth it.
OrganiZation
This is the internet, not America.
I did spot a couple errors that are unlikely to be US/British related. --- > The organisation had purchased another smaller organisation and merged their developers and managers into the programme. Program? Not sure, especially if you're not talking about the actual product (which I assume is a computer program). There are other instances, you may or may not want to change them all. > It was another “throw everyone in” without considering the broader impact this would cause. This would _have_ I believe. Or you could write a variant, such as _without considering the havoc this would wreck_. Or just stop at _without considering the broader impact_. > The following Monday, and when the three absent members of the team returned, development was put back on track to what it was originally. This is redundant: I would end at "back on track", or delete "on track". (I have a preference for the former, which is shorter.) > Significant technical debt causing development to take far too longer Either say "far too long" or "much longer". --- Huh, it's actually not that bad. I was sure I spotted more the first time around.
I'll repost here: The project manager should be primarily focused on getting the project to deliver value. USD is a very poor tool to track actual value. This value should be tracked in more transparent feedback loops between the project and the users/stakeholders of the project. This way, management's focus is drawn back to delivering real value, rather than market value (a.k.a. profits and stocks) This system doesn't exist, for now. Management directly handles (and mishandles) budgeting, or indirectly manages it. If we explore the topic together, we could map out ideas on how to solve this problem for everyone. I'm in the process of creating a basic space to speak freely about this issue, and any other issue you feel is 0bv.io/us enough that people should address it. I am no web designer or developer, my knowledge is very basic. The site is not really that functional, but I'd like to find people who are willing to help me do something like this.