I wonder what was wrong with the shell script thing really, other than it didn't have the panic button.
Big company tale: six months for a list and a button
41–50 of 91 posts
Re: Big company tale: six months for a list and a button
#42I keep reading from this author and it always struck me as a very capable technical person, but as an awful person to work with. There was a piece few days ago about picking co-founder using the army way. Beside being a well written piece, it made clear one thing. The role of leaders in an organisation is to get stuff done, despite rules, regulations, hierarchy and all the whistle and bells that an organisation need…
I got the same feelings. From the article:
> January 29, early: there's this team that nominally owns dashboards, and they got wind of us wanting a dashboard. They want to be the ones to do it, so we meet with them to convey the request.
> January 29, late: asked "dashboard team" manager if they had been able to get the network stuff talking to our server yet via chat. No reply.
Am I the only one to think this is completely unreasoanble to message the other team later that day? I mean it's not as if I am sitting and dangling my legs waiting for a Karen to come, drop everything I do and do her dashboard. They might have had stuff planned for weeks/months in advance...
Re: Big company tale: six months for a list and a button
#43I wonder what was wrong with the shell script thing really, other than it didn't have the panic button.
One possibility: kept boiling the oceans for no good reason 24/7 to generate something with three views per week.
Re: Big company tale: six months for a list and a button
#44I keep reading from this author and it always struck me as a very capable technical person, but as an awful person to work with. There was a piece few days ago about picking co-founder using the army way. Beside being a well written piece, it made clear one thing. The role of leaders in an organisation is to get stuff done, despite rules, regulations, hierarchy and all the whistle and bells that an organisation need…
I got the same feelings. From the article: > January 29, early: there's this team that nominally owns dashboards, and they got wind of us wanting a dashboard. They want to be the ones to do it, so we meet with them to convey the request. > January 29, late: asked "dashboard team" manager if they had been able to get the network stuff talking to our server yet via chat. No reply. Am I the only one to think this is com…
Yup. I pretty much stopped caring at that point. My backlog is 6+ months long. If you need me to drop something and pick up a new project, it’ll need the blessing of product management and, depending on size/LOE, also approval from my VP or SVP.
PM will adjust when appropriate; they do care. But, I can’t just build every little thing an internal customer wants because I have revenue-producing/cost-saving updates to build and deploy. Make your case that this lost+button saves more money than something else on my backlog, and we’ll probably squeeze it in.
This is a mid-sized enterprise software company and I manage one of our SRE teams.
Re: Big company tale: six months for a list and a button
#45I keep reading from this author and it always struck me as a very capable technical person, but as an awful person to work with. There was a piece few days ago about picking co-founder using the army way. Beside being a well written piece, it made clear one thing. The role of leaders in an organisation is to get stuff done, despite rules, regulations, hierarchy and all the whistle and bells that an organisation need…
While I agree completely that "human work and relationships building" in organizations is a more practical way to work with people than the author's strategy, if I were to call any of the people in the story "awful [...] to work with", it would have to be the people from the dashboards team, who apparently wanted to own the dashboard page but not have any of the responsibilities of actually building it. To be clear, it wasn't the author's preference to have another team build the page their team needed. The dashboard team insisted on doing things their way, then deprioritized the task, bungled the implementation, and finally delivered a trivial amount of work, six months after promising to do it.
And sure, everyone has different priorities, and may not understand the urgency of tasks in the same way. And it's only human to want to promise to do things for other people, and therefore make them happy. But promises by themselves aren't enough to get work done: when I'm in the workplace, I don't want wishes and happy thoughts, I want people to deliver. If someone tells me to hold off on doing a one-day project, because they're going to do it for me, and rest assured, it's on the roadmap, even though we won't tell you when we're going to do it, because quite probably, the answer will be something like "never, as long as we have more fun things to do" --- well then, at the very least I expect to be told as much, so I can avoid throwing my project into that particular black hole. If they can't, or won't, communicate realistic priorities and deadlines, then they might be great to eat lunch with, but I definitely don't want to work with them on a project.
Office jobs, in my opinion, tend to play host to microcultures which value politeness, sympathy, and relationship building so highly that these virtues start to displace and eclipse the honesty that is the cornerstone of serious, professional work. I come across this theme over and over in these kind of "story-rants", a theme that in the telling can come off as rudeness or abrasiveness on the author's behalf. Those who are keen to interpret it as such, should keep in mind that this says as much about them, and their own opinionated view of how the workplace should operate, as it does the authors of those stories.
Re: Big company tale: six months for a list and a button
#46Earlier quoted context omitted.
I got the same feelings. From the article: > January 29, early: there's this team that nominally owns dashboards, and they got wind of us wanting a dashboard. They want to be the ones to do it, so we meet with them to convey the request. > January 29, late: asked "dashboard team" manager if they had been able to get the network stuff talking to our server yet via chat. No reply. Am I the only one to think this is com…
Yup. I pretty much stopped caring at that point. My backlog is 6+ months long. If you need me to drop something and pick up a new project, it’ll need the blessing of product management and, depending on size/LOE, also approval from my VP or SVP. PM will adjust when appropriate; they do care. But, I can’t just build every little thing an internal customer wants because I have revenue-producing/cost-saving updates to b…
If your backlog is six-plus months long, do you simultaneously go out and “want to be the ones to do it”?
I have no problem with another team being too busy to take on work in my area, provided they don’t actively try to take on work in my area and then pocket veto it.
Re: Big company tale: six months for a list and a button
#47Earlier quoted context omitted.
Yup. I pretty much stopped caring at that point. My backlog is 6+ months long. If you need me to drop something and pick up a new project, it’ll need the blessing of product management and, depending on size/LOE, also approval from my VP or SVP. PM will adjust when appropriate; they do care. But, I can’t just build every little thing an internal customer wants because I have revenue-producing/cost-saving updates to b…
If your backlog is six-plus months long, do you simultaneously go out and “want to be the ones to do it”? I have no problem with another team being too busy to take on work in my area, provided they don’t actively try to take on work in my area and then pocket veto it.
This is the real core of the issue. There's always a chance that some software project, small or large, will progress massively slow for 1000 reasons. But the dysfunction with turf wars and actively blocking solutions is really serious, and common in large or growing companies.
Re: Big company tale: six months for a list and a button
#48They need a project management system.
This probably is their project management system.
As someone else pointed out, a request for an internal tool is going to be sorted behind something that is revenue-generating.
Re: Big company tale: six months for a list and a button
#49I keep reading from this author and it always struck me as a very capable technical person, but as an awful person to work with. There was a piece few days ago about picking co-founder using the army way. Beside being a well written piece, it made clear one thing. The role of leaders in an organisation is to get stuff done, despite rules, regulations, hierarchy and all the whistle and bells that an organisation need…
I take her articles as wakeup calls. She points out ridiculous behavior patterns in companies by telling stories from her hands on ops perspective. As a industry we talk a lot about agility but stories like that are more the norm than the exception. It is good to see an outside perspective on what is expected. Typical customers swallow our behaviors due to the lack of understanding but an IT ops like her just knows w…
> stories like that are more the norm than the exception
And most of the time, nobody learns from the experience when it happens to others, or even to themselves. "Learning from failure" is one of the most overused and most underutilized mottos in tech companies.
Re: Big company tale: six months for a list and a button
#50See also: a Web Server Installation story from The Daily WTF. https://thedailywtf.com/articles/web-server-installation It took 33 days for the sysadmin to get access permissions, before the project was cancelled one more month later. Comment: So, everything went smoothly?
Amazing reading. Though I wonder if the migration is canceled, or that the Client simply lost faith after 2 months and simply found another solution.