New answers tagged

1

Yes, bad management is typical. The core philosophy apparent here is something called "theory X" management. Ie, the developers are lazy and will do no work if at all possible, so they must be monitored in a very precise and public way. I'm not saying an authoritarian, low trust approach never works in any industry. But at least in software, one ...


0

Once you publish these numbers, even if management doesn't actively reward/punish developers based on these number, developers are going to compare themselves to others. They're going to try to establish themselves as someone who produces a low number of defects. While that's probably exactly what the PM is hoping for, it has a number of undesirable side ...


2

These kind of stats are usually a warning sign of a software package stagnating and dying. The other 2 answers have covered a lot but I will add a few things: Productive developers make mistakes, bad developers have never made any: "Move fast and break things" has a higher upper bound for productivity and research. You'll advance in your field ...


-1

There's a saying that I learned many years ago: If you work a lot, you make a lot of mistakes. If you work less, you make fewer mistakes. If you don't work at all, you make no mistakes. If you make no mistakes, you get promoted. Also known as the law of unintended consequences. As a software developer, when I develop a feature, there is a point where it's ...


2

In some countries this could even be illegal without the approval of labor unions, so where you are matters a lot. But leaving the legal aspect aside: this may lead to unwanted consequences: people working too much and burning out people afraid of committing mistakes to the degree that stops them from trying to do anything but the bare minimum ruining the ...


5

In sales, they have a saying: "Don't confuse your customers!" In this case, management is your customer, and you have confused them with technical stuff. Let's look at your problem in detail: (Highlighting by me) There's an implementation decision to be done. I've prepared all possible information to enable senior stakeholders to take an informed ...


1

You're only analysing the symptoms. You need to solve the core issue first of which there are at least 2. Firstly and most importantly you're not being trusted inasmuch as the information you're giving is repeatedly being questioned. Secondly you're putting too much into this whole problem, you have already solved your portion. You should be at the stage ...


8

So there should never been a problem with you inspecting processes used at a job interview, it should actually be the standard to ensure you completely understand all the processes in the workplace before you decide to work for them, otherwise it can lead to issues for them and you. They don't want to hire someone who will quit before three months, and ...


6

So your weakness is not communication skills. Your problem is that: when working without brief or being given oral one you tend to inquire a lot into topic. More than when working with written one. Reason for this might be you have time to do research/check information or you can just easily go back to previous point when reading. So this "weakness"...


2

My experience with PMP is that it is a way to check a box. I see it as a requirement on the contracts we bid on. The government wants people in these positions to Have Security+; in those positions they want certification from Oracle, in another group they need a help desk certification; and all will be led by somebody with PMP. It is there because they use ...


2

Based on that information, would it be wise to let my PMP certification expire? Based on all that information and priorities you have, I think you have answered yourself: it seems logical that it's best for your interests to focus on your entrepreneurship over renewing your certificate. Think of it like this: the window of opportunity for an ...


0

There are a lot of great answers here but one thing I have not seen mentioned yet is the application of Value Stream Mapping (aka Value Stream Analysis) on your SDLC and Development Operations processes. By mapping out your current workflow of how an idea becomes a requirement... becomes an actively worked story... is developed into compilable piece of code.....


1

So, I've done this through 4 companies now as a manager of medium sized (5-20 people) teams. And I think there's different tools for a couple of different jobs: Retrospectives (Agile) & Lessons Learned Good for stuff that is somewhat like a scrum - a way for a team to look back reflectively. Good for finding the stuff that doesn't fit into a single ...


2

As many have said, avoid finger pointing. People make mistakes, and that is part of the cost of business. Or, as I like to say, you pay for training one way or another A process that I've seen work very well is, and in this order: Fix Repair/resolve Investigate Resolve FIX Do whatever you need to do to get the systems up and running. It can be pretty or ...


2

Development standards and guidelines Large teams can coordinate based on shared documents, such as writing down specific standards and guidelines for various aspects of development, deployment, etc, specifying the common understanding for what is best practice in this company, which tradeoffs are preferrable, and what are the core standards that should be ...


38

You are in luck, there is a lot of contemporary work on conducting constructive incident retrospectives out there to learn from technical problems. It's referred to as "incident postmortems," "(post-) incident analysis," or "incident retrospectives." The 2010 book Web Operations included a paper called How Complex Systems Fail ...


102

The moment people realize that there is blame being handed out they will obfuscate and hide their mistakes as best they can, scapegoating others and generally making it impossible to learn anything useful. A much better idea is to do a no-blame post-mortem of the project. The goal is to go over the entire project from start to finish, examining at each stage ...


4

Here's how my old QA department did it, based on the 5-whys You start with the problem. "why did we ship a fault widget?" and find the most obvious cause, let's say: "because Bob didn't check it properly." Some companies would just fire Bob and call it a day, but there's no guarantee that the next guy will do any better. So you have ...


2

Berry has a solid answer. But there is no 'best approach'. There are other strategies and a lot depends on the company culture, perhaps even locale. Sometimes the team doesn't get much of a say. They effed up under pressure, an expert evaluates the situation and devises protocols and procedures to mitigate against it happening again with minimal input from ...


8

By technical problems I am not referring to small bugs but issues that caused serious disruption either to the business/customers or to other developers. If you're talking about serious one-off issues, you're looking to have a post-mortem. You can run the post-mortem in whatever way you like, but you're typically looking to drill down on what happened, the ...


18

I may have a unique perspective on this; In hindsight, when I was younger (late 20s) and put in charge of a small team, I had an employee under me in their early 50s quit, and give an exit interview very similar to what you've written. Apparently I "didn't recognise his contributions" or "value his opinion", or "use him to his best ...


2

How would you say your relationship is with the quality of your work? Not, "do you think you're good at your job", because everyone would say "yes" to that, even just out of arrogance. What I mean is, if I went and surveyed everyone on your team, how many of them do you think would tell me that you are good at your job? This includes ...


5

Time for another Zoom meeting, friend – with your new manager, one-on-one. Discuss your entire situation, as you have just done with us, "as you see it." Then, constructively ask how he sees it. Where is the common ground? What's best for the project? For the team? For you as a part of that team? Then: shut-up and listen. Don't interrupt. &...


4

I'm keying off one specific phrase: ...while engaging in meaningful debates with others My own manager has mentioned this to me in our own one-on-ones. There is one very senior level engineer on my team (equivalent in position to me) who tends to have a very different perspective than I do. And we have gotten into some very spirited debates as to who is ...


9

when I try to add something he often cuts me off with stern "okay", "yes sir" or "understood" When your manager says this, say something like "Wait just a moment, I wasn't done with my thought." The point here is assume good intent on his part and communicate that you weren't finished. If you're not comfortable doing ...


Top 50 recent answers are included