4 ms·

While not as applicable in situations where the engineering team isn't under much pressure to deliver, there's a pretty common negative feedback loop that can o

While not as applicable in situations where the engineering team isn't under much pressure to deliver, there's a pretty common negative feedback loop that can occur with engineer staffing. While under pressure, teams with an adequate or bountiful number of skilled members will generally perform pretty darned well and not have a problem. If anything causes the balance to start tipping too much in the ratio with unskilled team members then the skilled members will feel more internal career growth based pressure to find work elsewhere. As they start to slowly phase out to other locations the ratio gets even worse, the quality of the product gets worse, and the moral gets worse. All of this causes more incentive for the skilled engineers that are still left to leave as well. Unfortunately as this happens a higher number of deliverables will be missed and more bugs will arise alerting management that they somehow have become a less productive shop. This is where you can readily identify bad engineering management. Instead of tackling the root of the problem many places double down by increasing pressure to deliver and by relaxing standards as to who they hire. Once this happens you've unfortunately started the process of being a sinking ship. This can be righted in time depending on how large the company's coffers or how tight of a hold they have on the market but growth generally will have peaked by this point. What management should have done (or needs to do ASAP) was to start trimming poor performing engineers. Yes firing people is hard, yes it sucks getting rid of workers when you're already behind schedule. But any good engineers you manage to trick into joining this dysfunctional team will likely leave within the first few months anyways. Relaxing pressure to deliver WHILE fixing the poor performers issue can also help slow down the rate you're losing good performers at least for a short period. I've seen this at many many places. Currently still in one of these situations because they keep throwing more money at me to stay but even with that I've started looking again because the situation is not helping my career growth as much as I wish. edit: IpV8's checklist is also really important to look for and lack of that could cause the start of tipping the balance as mentioned above.

thrwwyngnr 8y ago
> What management should have done (or needs to do ASAP) was to start trimming poor performing engineers. Oh, we did that in 2017. The engineers are hard workers and good coders. Thing is, there aren't really individual performance problems. The problems are mostly cultural: Isolation from the rest of the company, in-fighting, competition, lack of camaraderie between teams and between engineering and the rest of the organization. When it comes to team performance, half the team believes we're too slow, while the other half thinks we're moving too fast. Even that is a point of disagreement.
- scottdwitt 8y ago
  Your company has a LEADERSHIP Problem! And the 'cultural' problems: isolation, in-fighting, counter-productive competition, are symptoms. Your 'leaders' have hired misguided Engineering Managers who created an environment that made this behavior possible, and your leadership is allowing it to continue. > First Question: Are your founders / leaders Engineers? > Second Question: Why do team members think that you're moving too-slow / too-fast?
  - thrwwyngnr 8y ago
    > Are your founders / leaders Engineers? Actually, yes. They wrote the software that is currently used in production. But they don't want to touch engineering with a ten-feet pole. One time they complained that engineering was taking too long to finish stuff and engineering demanded an apology. > Why do team members think that you're moving too-slow / too-fast? Good question. Both sides provide very good arguments, but they're super polarized. Half the team is the MVP-lean-startup-crowd and is constantly complaining that the code is too complex, with too many abstractions and it is and hard to test and debug. They claim they want to push simpler code that works and optimize/refactor as needed, but that never flies on code reviews. They claim that the constant refactoring (I swear I hear that word ten times a day) are causing way too many bugs. The other half comes from an enterprise background and complains that the code is currently too messy and unsafe, and claim they need to refactor weird parts before doing pretty much any feature. They believe in making bigger deliveries instead of incremental ones, and point to bugs caused by the other team as proof that they need more time to get it right. For obvious reasons, management has ALWAYS sided with group number one, which caused a lot of problems and accusations of favoritism. My hot take? Yeah, three years is way too long for a simple web app from a startup to be ready.
    - cbanek 8y ago
      >> Are your founders / leaders Engineers? > Actually, yes. They wrote the software that is currently used in production. > But they don't want to touch engineering with a ten-feet pole. One time they complained that engineering was taking too long to finish stuff and engineering demanded an apology. Engineers can get very touchy about code they write. It's kind of their baby. It sounds like the highest levels of management have written what is being run, and yet not want to seem to maintain it, or directly lead the engineering org. Then they also want a great engineering team to improve what they've been doing, which inevitably ends up being ways that the initial implementation could have been done better. Sounds like a double bind for the employees. If an employee finds a much better way of doing things, the founders should be happy, but they may be sending mixed signals. Another example is that when you've written a bunch of code, you are the expert. Anyone else working on it will be going slower, because they don't have the background that the initial author did. If there are two sides, and one says that the code is too complex, and the other side says it's messy and unsafe I'm likely to believe both of them. For different parts of the code, you may need incremental improvement, or you may need to rewrite it. This is where you need real engineering leadership.

thrwwyngnr 8y ago

> What management should have done (or needs to do ASAP) was to start trimming poor performing engineers. Oh, we did that in 2017. The engineers are hard workers and good coders. Thing is, there aren't really individual performance problems. The problems are mostly cultural: Isolation from the rest of the company, in-fighting, competition, lack of camaraderie between teams and between engineering and the rest of the organization. When it comes to team performance, half the team believes we're too slow, while the other half thinks we're moving too fast. Even that is a point of disagreement.

scottdwitt 8y ago
Your company has a LEADERSHIP Problem! And the 'cultural' problems: isolation, in-fighting, counter-productive competition, are symptoms. Your 'leaders' have hired misguided Engineering Managers who created an environment that made this behavior possible, and your leadership is allowing it to continue. > First Question: Are your founders / leaders Engineers? > Second Question: Why do team members think that you're moving too-slow / too-fast?
- thrwwyngnr 8y ago
  > Are your founders / leaders Engineers? Actually, yes. They wrote the software that is currently used in production. But they don't want to touch engineering with a ten-feet pole. One time they complained that engineering was taking too long to finish stuff and engineering demanded an apology. > Why do team members think that you're moving too-slow / too-fast? Good question. Both sides provide very good arguments, but they're super polarized. Half the team is the MVP-lean-startup-crowd and is constantly complaining that the code is too complex, with too many abstractions and it is and hard to test and debug. They claim they want to push simpler code that works and optimize/refactor as needed, but that never flies on code reviews. They claim that the constant refactoring (I swear I hear that word ten times a day) are causing way too many bugs. The other half comes from an enterprise background and complains that the code is currently too messy and unsafe, and claim they need to refactor weird parts before doing pretty much any feature. They believe in making bigger deliveries instead of incremental ones, and point to bugs caused by the other team as proof that they need more time to get it right. For obvious reasons, management has ALWAYS sided with group number one, which caused a lot of problems and accusations of favoritism. My hot take? Yeah, three years is way too long for a simple web app from a startup to be ready.
  - cbanek 8y ago
    >> Are your founders / leaders Engineers? > Actually, yes. They wrote the software that is currently used in production. > But they don't want to touch engineering with a ten-feet pole. One time they complained that engineering was taking too long to finish stuff and engineering demanded an apology. Engineers can get very touchy about code they write. It's kind of their baby. It sounds like the highest levels of management have written what is being run, and yet not want to seem to maintain it, or directly lead the engineering org. Then they also want a great engineering team to improve what they've been doing, which inevitably ends up being ways that the initial implementation could have been done better. Sounds like a double bind for the employees. If an employee finds a much better way of doing things, the founders should be happy, but they may be sending mixed signals. Another example is that when you've written a bunch of code, you are the expert. Anyone else working on it will be going slower, because they don't have the background that the initial author did. If there are two sides, and one says that the code is too complex, and the other side says it's messy and unsafe I'm likely to believe both of them. For different parts of the code, you may need incremental improvement, or you may need to rewrite it. This is where you need real engineering leadership.