10 ms·

Having led a team for about a year now let me tell you it's not easy. You are always trying to balance many priorities and even with over a decade of coding exp

Having led a team for about a year now let me tell you it's not easy. You are always trying to balance many priorities and even with over a decade of coding experience, it's not always obvious which refactorings or tech debt stories or architectural changes are worth prioritizing now, which can wait till later, and which are engineer pipe dreams that I need to gently but firmly kill as quickly as possible. I have had similar managers to what was described above, in those types of organizations. It may be a lost cause but it may be an opportunity to work on your influence skills; being able to explain and sell your solution is perhaps even more important than coming up with it in the first place.

deleted 6y ago
[deleted]
tacitusarc 6y ago
This is really difficult. Perhaps the best thing is to track the proposed technical debt stories, and do not discard them when they are rejected. Instead, also keep track of how much pain is hit that can be associated back to that particular technical debt. 3 years into major project, my team finally got prioritized to work on and improvement that will take us a couple weeks, that we were not able to work on previously because we could not justify its value. But for the past 3 years the organization has lived with pain that this would have resolved. So now we can justify it. And the thing is, it's not like we didn't know 3 years ago when we said we wanted to make this happen but things are going to be terrible if we were not able to prioritize it but in many organizations it's not good enough to just say how bad things will be. People need to actually have felt the pain. Honestly, I think that's okay on its face. My bigger issue is that frequently there is no or very little trust around engineers who predict what the major problems will be an advocate for them and then it's not like when they're proven right management now listens to them the next time. I think that's the real problem.
- kclay 6y ago
  In these cases wouldn't it have been to work on it slowly as a "side project" outside of the team normal priorities? I always tell my team if they can fit it in and not hinder the current sprint by all means go ahead and do it on the side. I know this goes against the normal and people want to attach "right now " value (hours it took reflected on check) but going beyond the call can also give you leverage when your yearly review comes up for example.
  - pdimitar 6y ago
    That's exactly what I am doing and aside from a few wrist slaps people have been okay with such an approach. I always tell them I did this for a few hours during the weekend or while I was waiting our DevOps to resolve an outage these particular 2 hours the last Friday. Seems to work really well.
  - hpoe 6y ago
    I'll also add I only have so much energy in the day, and after a couple of years of fighting against problems I coudn't do anything about and managers who couldn't make the changes, and customers that wanted it now, I burnt out, and instead of spending a useless zoom meeting to work on an improvement I use it instead to make maps for the D&D campaign I am running.
  - Too 6y ago
    While I've seen several examples of this being the only way to get out of never prioritized debt-cleanup that the team can't bother explaining to management in non-technical business-value terms. The reality is a sprint is always over-packed with stuff to do with zero room for side-projects and expecting people to work weekends on side-projects to solve company business needs is not exactly a sound strategy. What one can do is is deliberately allot time to the team to work on any side-project as long as they are somehow attached to the business. There are ways to do this more organized, for example innovation-weeks or the famous Google-fridays.
  - tacitusarc 6y ago
    That can work assuming the team isn't already overloaded. But when people are being asked to work 60h a week or more to accomplish their tasks, it becomes untenable.
- mavelikara 6y ago
  > My bigger issue is that frequently there is no or very little trust around engineers This is a problem. But at any given time management hears programmers arguing for both sides - the "if you're not using Kubernetes you're a moron" and the "learn how to sysadmin and you'll realize you don't need Kubernetes in the first place" (quotes from the top of the thread). In many cases folks in senior management do not have any idea of these things, and they rely on one of these two opinions, resulting in the other half claiming here on HN that management is all bull. What the profession lacks is a code of practices - like a Joel Test accepted by every accredited engineer. I am not sure that is net positive for such a rapidly evolving space. Even now people are debating if unit tests are needed and other basic topics. The only "settled" thing about the profession seems to be that gotos are bad.
  - psahgal 6y ago
    I find that the best senior engineers don't say "if you're not using Kubernetes you're a moron" and "learn how to sysadmin and you'll realize you don't need Kubernetes in the first place", but instead say "Kubernetes is fantastic for this use case because of these reasons..." and "sysadmin would be easier to use than Kubernetes for this problem because of these reasons..." I'm not sure how one gets software engineers to justify and back up their decisions like this on a regular basis, but I suspect it would help management trust their engineers more.
    - lanstin 6y ago
      (Bad) Management chooses to listen to engineers that say agreeable things, not true things.
      - psahgal 6y ago
        If your manager listens to the engineer who says "Kubernetes is awesome and does all the things!" and doesn't listen to the engineer who says "I think Kubernetes is a bad idea for this project because x, y, and z", then yeah, it's time to find a new manager. Good managers listen to good advisors.
    - 6y ago
- z3t4 6y ago
  > People need to actually have felt the pain. Just like those that never have been hacked dont care about security. Or those that have never lost data dont care about backups. Or those who has never had more then 10 simultaneous users dont care about performance. Basically we do stuff in order to avoid pain.
pdimitar 6y ago
I wholeheartedly agree that we the engineers must work on our non-tech talking skills! I've been working on it for a few years now and it's REALLY difficult but even the small wins feel very rewarding and are motivating me to refine my comm skills further.

deleted 6y ago

[deleted]

tacitusarc 6y ago

This is really difficult. Perhaps the best thing is to track the proposed technical debt stories, and do not discard them when they are rejected. Instead, also keep track of how much pain is hit that can be associated back to that particular technical debt. 3 years into major project, my team finally got prioritized to work on and improvement that will take us a couple weeks, that we were not able to work on previously because we could not justify its value. But for the past 3 years the organization has lived with pain that this would have resolved. So now we can justify it. And the thing is, it's not like we didn't know 3 years ago when we said we wanted to make this happen but things are going to be terrible if we were not able to prioritize it but in many organizations it's not good enough to just say how bad things will be. People need to actually have felt the pain. Honestly, I think that's okay on its face. My bigger issue is that frequently there is no or very little trust around engineers who predict what the major problems will be an advocate for them and then it's not like when they're proven right management now listens to them the next time. I think that's the real problem.

kclay 6y ago
In these cases wouldn't it have been to work on it slowly as a "side project" outside of the team normal priorities? I always tell my team if they can fit it in and not hinder the current sprint by all means go ahead and do it on the side. I know this goes against the normal and people want to attach "right now " value (hours it took reflected on check) but going beyond the call can also give you leverage when your yearly review comes up for example.
- pdimitar 6y ago
  That's exactly what I am doing and aside from a few wrist slaps people have been okay with such an approach. I always tell them I did this for a few hours during the weekend or while I was waiting our DevOps to resolve an outage these particular 2 hours the last Friday. Seems to work really well.
- hpoe 6y ago
  I'll also add I only have so much energy in the day, and after a couple of years of fighting against problems I coudn't do anything about and managers who couldn't make the changes, and customers that wanted it now, I burnt out, and instead of spending a useless zoom meeting to work on an improvement I use it instead to make maps for the D&D campaign I am running.
- Too 6y ago
  While I've seen several examples of this being the only way to get out of never prioritized debt-cleanup that the team can't bother explaining to management in non-technical business-value terms. The reality is a sprint is always over-packed with stuff to do with zero room for side-projects and expecting people to work weekends on side-projects to solve company business needs is not exactly a sound strategy. What one can do is is deliberately allot time to the team to work on any side-project as long as they are somehow attached to the business. There are ways to do this more organized, for example innovation-weeks or the famous Google-fridays.
- tacitusarc 6y ago
  That can work assuming the team isn't already overloaded. But when people are being asked to work 60h a week or more to accomplish their tasks, it becomes untenable.
mavelikara 6y ago
> My bigger issue is that frequently there is no or very little trust around engineers This is a problem. But at any given time management hears programmers arguing for both sides - the "if you're not using Kubernetes you're a moron" and the "learn how to sysadmin and you'll realize you don't need Kubernetes in the first place" (quotes from the top of the thread). In many cases folks in senior management do not have any idea of these things, and they rely on one of these two opinions, resulting in the other half claiming here on HN that management is all bull. What the profession lacks is a code of practices - like a Joel Test accepted by every accredited engineer. I am not sure that is net positive for such a rapidly evolving space. Even now people are debating if unit tests are needed and other basic topics. The only "settled" thing about the profession seems to be that gotos are bad.
- psahgal 6y ago
  I find that the best senior engineers don't say "if you're not using Kubernetes you're a moron" and "learn how to sysadmin and you'll realize you don't need Kubernetes in the first place", but instead say "Kubernetes is fantastic for this use case because of these reasons..." and "sysadmin would be easier to use than Kubernetes for this problem because of these reasons..." I'm not sure how one gets software engineers to justify and back up their decisions like this on a regular basis, but I suspect it would help management trust their engineers more.
  - lanstin 6y ago
    (Bad) Management chooses to listen to engineers that say agreeable things, not true things.
    - psahgal 6y ago
      If your manager listens to the engineer who says "Kubernetes is awesome and does all the things!" and doesn't listen to the engineer who says "I think Kubernetes is a bad idea for this project because x, y, and z", then yeah, it's time to find a new manager. Good managers listen to good advisors.
  - 6y ago
z3t4 6y ago
> People need to actually have felt the pain. Just like those that never have been hacked dont care about security. Or those that have never lost data dont care about backups. Or those who has never had more then 10 simultaneous users dont care about performance. Basically we do stuff in order to avoid pain.

pdimitar 6y ago

I wholeheartedly agree that we the engineers must work on our non-tech talking skills! I've been working on it for a few years now and it's REALLY difficult but even the small wins feel very rewarding and are motivating me to refine my comm skills further.