Any advice for communicating challenges upwards? I'm not interested in becoming a manager, but as a 'senior' person I see a lot of things that are... less than optimal, but framing these challenges(ignoring technical debt in favour of pushing out new features, ignoring 'flaky' tests because we don't have time to investigate and harden the suite, etc) to people without a development background can be difficult, and ultimately, their priorities will override mine.
I started writing software in 1984. Over the years I worked with many languages, technologies, and tools. I have been in leadership positions since the early 2000s, and in executive roles since 2014.
Yes. To be able to effectively communicate the importance and priority of dealing with technical debt you need to figure out how to quantify the cost of not doing the work and the added value of doing it. In other words, you need to give non-technical decisions makers a way to compare their list of priorities with yours. For example, you could come up with something like: "if we don't fix this issue, we will never be able to scale past X number of requests per day. Given the traffic trends, we'll be there in Y months..."
So... the trick is to convert technical needs into non-technical values.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Any advice for communicating challenges upwards? I'm not interested in becoming a manager, but as a 'senior' person I see a lot of things that are... less than optimal, but framing these challenges(ignoring technical debt in favour of pushing out new features, ignoring 'flaky' tests because we don't have time to investigate and harden the suite, etc) to people without a development background can be difficult, and ultimately, their priorities will override mine.
Yes. To be able to effectively communicate the importance and priority of dealing with technical debt you need to figure out how to quantify the cost of not doing the work and the added value of doing it. In other words, you need to give non-technical decisions makers a way to compare their list of priorities with yours. For example, you could come up with something like: "if we don't fix this issue, we will never be able to scale past X number of requests per day. Given the traffic trends, we'll be there in Y months..."
So... the trick is to convert technical needs into non-technical values.