Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "management directors"
-
A seasoned colleague just wrote this and I think it was very valuable:
On tech debt:
So the big challenge with technical debt is making non-technical management (CEO, COO, CFO, directors) understand what it means, and just how it operates. Sometimes it actually makes good sense to incur technical debt to get to market sooner, just as it sometimes makes sense to borrow money to get cash now and repay that loan later with (hopefully) resulting greater revenues from that investment. But just like a loan, tech debt always has to be paid some day. The longer the tech debt goes, the more expensive it gets. And also like a loan, the cost compounds, like compound interest on a loan. Tech debt should always be chosen with a clear plan to pay it off at some point in the not too distant future. The longer one waits to pay it, the more expensive it gets.7 -
This is my most ridiculous meeting in my long career. The crazy thing is I have witnessed this scenario play out many times during my career. Sometimes it sits in waiting for a few years but then BOOM there it is again and again. In each case the person that fell into the insidious trap was smart and savvy but somehow it just happened. The outcomes were really embarrassing and in some cases career damaging. Other times, it was sort of humorous. I could see this happening to me and I never want it to happen to you.
Once upon a time in a land not so far away there was a Kickoff Meeting for an offsite work area recovery exercise being planned for our Oklahoma locations. Eleven Oklahoma high ranking senior executives were on this webinar plus three Enterprise IT Directors (Ellen, Jim and Bob) who would support the business from the systems side throughout the exercise.
The plan was for Sam Otto, our Midwest Director of Business Continuity to host this webinar. Sam had hands-on experience recovering to our third party recovery site vendor and he always did a great job. He motivated people to attend the exercise with the coolest breakfasts and lunches you could imagine. Donuts, bagels, pizza, wings, scrumptious salads, sandwiches, beverages and desserts. He was great with people and made it a lot of fun.
At the last minute Charles 'Don't Call Me Charlie' Ego-Smith, the Global Business Continuity Senior Vice President, decided to grand-stand Sam. He demanded the reins to the webinar. Pulled a last-minute power-play and made himself the host and presenter. You have probably seen the move at some point in your career. I guess the old saying, 'be careful what you wish for' has some truth to it - read on and let me know if you devRanters agree...
So, Charlie, I mean Charles, begins hosting the session and greets all of the attendees. Hey, good so far! He starts showing some slides in the PowerPoint presentation and he fields a few questions, comments and requests from the Oklahoma executives. The usual easy to handle requests such as, 'what if we are too busy to do recover all systems', 'what if we recover all of our processes from home', 'what if we have high profile visitors that month?' Hey you can't blame them for trying. You are probably thinking to yourself, 'been there - heard that!' But luckily our experienced team had anticipated the push-back. Fortunately, Senior Management 'had our backs' and committed that all processes and systems must participate and test - so these were just softball requests, 'easy-peasy' to handle. But wait, we are just getting started!
Now the fireworks begin. Bob, one if the Enterprise IT directors started asking a bunch of questions. Well, Charles had somewhat of a history with Bob from previous exercises and did not take kindly to Bob's string of questions. Charles started getting defensive and while Bob was speaking Charles started IM'ing. He's firing off one filthy message after another to me and our teammate Sam.
'This idiot Bob is the biggest pain in the ass that I ever worked with'; 'he doesn't know shit', 'he never shuts the f up', 'I wanna go over to his office and kick his f'in ass...!'
Unfortunately...the idiot Charles had control of the webinar and was sharing his screen so every message he sent was seen by all of the attendees! Yeah, everyone including Bob and the Senior Oklahoma executives! We could not instant message him to stop as everyone would have seen our warnings, so we tried to call Charles' cell phone and text him but he did not pick up. He just kept firing ridiculously embarrassing dirty IM messages and I guess we were all so stunned we just sat there bewildered. We finally bit the bullet and IM'ed him to STOP ALREADY!!! Whoa, talk about an embarrassing silence!
I really felt sorry for Bob. He is a good guy. Deservedly, Charlie 'Yes I am going to call you CHARLIE' got in big time hot water after the webinar with upper management. For one reason or another he only lasted another year or so at our company. Maybe this event played a part in his demise.
So, the morale is, if you use IM - turn it off during a webinar if you are the host. If you must use it, be really careful what you say, who you say it to and pray nothing embarrassing or personal is sent to you for everyone to see.
Quick Update - During the past couple of months I participated on many webinars with enterprise software vendors trying to sell me expensive solutions. Most of the vendors had their IM going while doing webinars and training. Some very embarrassing things came flying across our screens. You learn a lot reading those messages when they pop-up on the presenters' screen, both personal and business related. Some even complaints from customers!
My advice to employees and vendors is to sign-out of IM before hosting a webinar. Otherwise, it just might destroy your credibility and possibly your career.5 -
I'm unbelievably angry. So please bear with my venting.
QA guy and I are stuck working the entire weekend. A few months ago our company decided to promote an account manager to a Product/Project management role with 0 experience and offering them 0 training. They have no experience working with devs and have been making our lives hell. I work easily 50-60hrs per week and they still budget projects according to 40hrs/week meaning they're stealing my time not to mention they're incorrectly setting the client's and company's expectations.
They now have complete control over roadmaps, client communications (this wouldn't normally be bad except that they're having technical discussions with the client with 0 tech experience), timelines, etc. and since their experience was in account management they are now working with devs but making decisions that exclusively put the client first at all costs, even if it means everyone else has to work weekends while they go on vacation!!!!
I've approached them several times to offer help on budgeting time or to propose that we do a Q4 planning so that we can improve the product instead of stay in a shitty position as we are. I'm responded with "You deal with what's in front of you. It's my job to look at the bigger picture."
They mismanaged a $500,000 project and our CEO got wind of it because the client called him while he was travelling. He in turn gave shit to our Directors who in turn chewed the QA guy and I out. "You need to be more meticulous when deploying. How could you let this happen? We're eating shit because of this. You need to work over the weekend to make up for this", etc.
I'm now directly responsible for having delivered something that wasn't up to standards even though I was already putting in the overtime.
This is honestly fucking ridiculous. How can I be blamed when I'm truly doing the best I can and putting as many hours as I can while edging toward burnout.
I love what I do but I hate feeling extremely pressured to turn down friends and family like this. Maybe I'm just too easy going and need to say no more. Who fucking knows. I know that I'm angry with the company right now.
What do you all think? If you read this rant, thank you. Feels better to write it out.13 -
I have seen it. They say it doesn't exist; just a story we tell our children so that their innocence does not lead them down into a nightmarish adulthood from which there is no salvation. But the evil lives. So vile that were you to look inside its soul, all you would find is a terrible desperation for suffering. To cause it. To revel in it. To bathe in the tears of those it considers less than human and feed off the emotional detritus.
It was 2009. The financial crisis. I was one of the lucky, having found refuge in a large company right before the jobs dried up. General IT: system administration, documentation, project management, telephony, software training, second level help desk. No software development, but with a two-year-old at home and Ph.D.s lining up outside the local Olive Garden whenever a help wanted sign was posted, I grabbed the health insurance and entered into darkness.
The Thing did not need to hunt it's prey. A manager title with 21 reports brought it new opportunities for fresh meat by the hour. But I was special. I resisted. I needed to know my place.
My first mistake was incomprehension. I did not understand the Thing's lust to be right at all costs. I was reviewing some documentation it had brought forth from its bowels. I mentioned that two spaces were being used between sentences. That proportional type made that unnecessary. It insisted, I was wrong. It insisted that Microsoft itself, the purveyor of all good technical writing, required two spaces. I opened the Microsoft Manual of Style for Technical Publications that it demanded its staff use and showed it that the spec was one space. It was livid. I was a problem.
From that point on my work life became exponentially more wretched. I was given three Outlook calendars to maintain: one with my schedule, one with the team's schedule and one with the Thing's schedule. Every time I had an appointment, I was to triple schedule it. If I was going to be away from my desk for more than 15 minutes triple schedule. Triple schedule my lunch, vacations, phone conferences.
Whenever it held a meeting, I and a colleague would be taken off mission critical IT projects to set tables with name tents and to serve as greeters as attendees arrived.
I was called into its crypt to be told never to say anything in a meeting unless I told the Thing beforehand what I was going to say. Naive, I mentioned that I often don't know what I will say as it is often in reply to someone else. Of course the response was that I should not say anything.
I would get emails 10-20 times a day asking about a single project. I would regularly complete work that was needed to be completed ASAP, only to have the Thing rake me over the coals for not completing it a week later. And upon resending the emails proving I notified it of the work being competed, disparaged at length a second time for not sending repeated notifications of the competed work.
I would have to sit in two-hour meetings to watch it type. Literally watch it try to create cogent thoughts. In silence.
I received horrendous annual reviews. At one, it created a development plan that stated a colleague would begin giving me lessons on the proper ways to socially interact with personnel. I pointed out to HR that this violated privacy concerns and would make the business liable in many areas, not least of which would be placing a help desk person in the role of defining proper business practice. HR made the Thing remove this from my review. She started planning to remove me.
I had given a short technical training to a group of personnel months earlier. Called into its tomb I was informed that feedback surveys on my talk were disturbing. One person stated that they did not think I was funny. Another wrote that I made an offensive statement. That person did not say what the offensive statement was. Just that I had said something he or she didn't like.
The Thing interviewed the training attendees. Gathered facts. Held three inquest-like meetings where multiple directors peppered me with questions trying to get me to confess to my offensiveness. In the end the request to fire me was brought to the man who ran the business at the time. The statement on high: "Humor is a subjective thing. Please tell This to be sensitive to that."
The Thing had failed, but would no doubt redouble its efforts. I had to find a new job. I sent hundreds of resumes. Talked to dozens of recruiters. But there were no jobs. And I had a family. And the wolf was at the door.
So I didn't say a word to the creature. For six months. Silence. At one group meeting it shrieked at me "what are you smirking at? If you've got something to say then say it!" I just shrugged. For my salvation was revealed. The Thing could not stand to be ignored. And at the end of my penance I was transferred to another group: Software Development.
I am one with the Force. The Force is with me. I am one with the Force. The Force is with me.4 -
Delivering next 6 month’s product roadmap to CEO, other directors and senior management.
I know it’s all going to change.
They know it’s all going to change.
I know they know.
They know I know.
No words are spoken. -
I have arrived at a conclusion that most, if not all, people in management (managers, sr managers, directors, VPs, etc) are assholes.
And every single person who is hands on with their skill is gold of a human being.
I think, to be a manager, the basic criteria is to be an asshole. Fuckers ignore you, discourage you, belittle you in front of everyone, never help you, and make your life difficult as much as they can.
That totally ruins the productivity and moral of a person.
Welcome to Capitalism, Floyd.
And person who is hands on, knows and has fuck ton of more knowledge and wisdom needed to achieve something. They are very helpful and nice.
Just bagging a heavy pay check and making crappy decisions doesn't make you a good boss.14 -
Having a director who only got his position because the industry is so young and he was able to register domain names so seen as an expert by non-technical people. As few people do this role where I live he was able to move from role to role and rise up the ranks. Everyone in the company knows he's useless except a couple of older directors who are scared of technology so think he's knowledgeable.
He has no ability to plan, everything he says to clients is 'yes, asap' without getting proper requirements, then pulls the devs off one project mid progress to work on another. He also needs basic concepts explained to him many, many times. When pitching for work I end up writing most of his stuff for him and he also starts with the previous version of a document that I have proof read and corrected about ten times.
The frustrating part is I only have to deal with him due to a merger of two companies.1 -
Can someone explain to me why non-technical people even work in tech companies ??
I really don't want to sound like an asshole, but can you, for example, imagine that someone who doesn't even know what brick is would work on a construction site ?
Or can you imagine working in bike repair shop not knowing neither how to ride a bike nor how's bike is built ?
Sure, every company (especially large ones) needs bookkeepers/HRs/accountants etc. that don't need to know the inner workings of business.
Those people don't bother me, and they are necessary to keep the circus going.
I'm talking about all those middle management individuals.
All those "Project Managers" , "Business Analysts", "Directors' , "Principal Program Managers " etc etc ..
Such thing thing would be unthinkable in every other industry but somehow, in tech, anyone can work as long as they can throw a sufficient number of acronyms around.7 -
I had a dream freelance job recently. It was a lot of a fun and I really wanted to continue to work there.
However it started to become apparent my manager was a mess. He would often turn up hungover and couldn’t follow conversation. When asked about docs he said he wouldn’t keep any documentation “so no one could take over”. The whole attitude and professionalism was awful.
Some days on release he (and another member of the team) would turn up to work four hours late as they’d been out the night before. I would absorb all of the impact. Technically I felt he was quite significantly junior than myself. Management saw, directors saw, no one did anything.
To cut a long story short - I raised it with HR, I was told unless I raised an “official grievance” nothing would be done. I asked if I could move - I was met with a shrug “we don’t know”
I eventually reached a point where I felt my only real power is to walk away.
I now have no confidence in HR at all. I don’t think I’ll ever involve or raise anything with them again. 😔6 -
A tale of silos, pivots, and mismanagement.
Background: Our consultancy has been working with this client for over a year now. It started with some of our back-end devs working on the API.
We are in Canada. The client is located in the US. There are two other teams in Canada. The client has an overseas company contracted to do the front-end of the app. And at the time we started, there was a 'UX consultancy' also in the US.
I joined the project several months in to replace the then-defunct UX company. I was the only UX consultant on the project at that time. I was also to build out a functional front-end 'prototype' (Vue/Scss) ahead of the other teams so that we could begin tying the fractured arms of the product together.
At this point there was a partial spec for the back-end, a somewhat architected API, a loose idea of a basic front-end, and a smattering of ideas, concepts, sketches, and horrific wireframes scattered about various places online.
At this point we had:
One back-end
One front-end
One functional prototype
One back-end Jira board
One front-end Jira board
No task-management for UX
You might get where this is going...
None of the teams had shared meetings. None of the team leads spoke to each other. Each team had their own terms, their own trajectory, and their own goals.
Just as our team started pushing for more alignment, and we began having shared meetings, the client decided to pivot the product in another direction.
Now we had:
One back-end
One original front-end
One first-pivot front-end
Two functional prototypes
One front-end Jira board
One back-end Jira board
No worries. We're professionals. We do this all the time. We rolled with it and we shifted focus to a new direction, with the same goals in mind internally to keep things aligned and moving along.
Slowly, the client hired managers to start leading everything in the same direction. Things started to look up. The back-end team and the product and UX teams started aligning goals and working toward the same objectives.
Then the client shifted directions again. This time bigger. More 'verticals'. I was to leave the previous 'prototypes' behind, and feature-freeze them to work on the new direction.
One back-end
One conceptual 'new' back-end
One original front-end
One first-pivot front-end
One 'all verticals' front-end
One functional prototype
One back-end Jira board
One front-end Jira board
One product Jira board
One UX Jira board
Meanwhile, the back-end team, the front-end team overseas, all kept moving in the previously agreed-upon direction.
At this stage, probably 6 months in, the 'prototypes' were much less proper 'prototypes' but actually just full apps (with a stubbed back-end since I was never given permission or support to access the actual back-end).
The state of things today:
Back to one back-end
One original front-end
One first-pivot front-end
One 'all verticals' front-end
One 'working' front-end
One 'QA' front-end
One 'demo' front-end
One functional prototype
One back-end Jira board
Two front-end Jira boards
One current product Jira board
One future product Jira board
One current UX Jira board
One future UX Jira board
One QA Jira board
I report to approximately 4 people remotely (depending on the task or the week).
There are three representatives from 'product' who dictate features and priorities (they often do not align).
I still maintain the 'prototype' to this day. The front-end team does not have access to the code of this 'prototype' (the clients' request). The client's QA team does not test against the 'prototype'.
The demos of the front-end version of the product include peanut-gallery design-by-committee 'bug call-outs', feature requests, and scope creep by attendees in the dozens from all manner of teams and directors.4