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 - "silos"
-
I'm stuck in a broken train with no more than 3% on my mobile phone... let this rant be my swan song!11
-
I manage a team of engineers.
Toxic Culture Post #2:
Manager: Everybody on your team needs their own swimlane in Jira. Each person's work should be their own lane. When I have a ticket for <Project A> I want to make sure that <Bob> always gets it, all tickets for <Project B> must go to <James>. You'll need to figure out which team member will handle <New Project C> and create their personal swim lane.
Me: That's not really how SCRUM works. Actually, that's not how teamwork works. You're creating silos and we all need to learn how to do these tasks. We're a cross-functional team, and each team member brings their own unique talents to the whole process.
Manager: So you'll create the swimlanes?
Me: No
Manager (to Bob): You'll be devoted to <Project A> from now own. It's the only work I expect you to do. All work for that project will be yours.
Likewise, my manager also reached out to each team member and assigned them specific tasks, furthering the silos.6 -
So, I recently picked up this book called "The Phoenix Project". I picked it up as I thought it was a project management text book. Turns out its a novel on how this Auto parts company's IT department broke down its silos and embraced DevOps. It's even framed as a thriller - the stakes always get higher! Extremely Exciting!
My Wife, kids and I listen to the audiobook as we drive and do errands every day. My Wife has gotten a very very frank understanding of what my job is like as a result.
I encourage everyone here to get a copy of the book. -
dev, ~boring
This is either a shower thought or a sober weed thought, not really sure which, but I've given some serious consideration to "team composition" and "working condition" as a facet of employment, particularly in regard to how they translate into hiring decisions and team composition.
I've put together a number of teams over the years, and in almost every case I've had to abide by an assemblage of pre-defined contexts that dictated the terms of the team working arrangement:
1. a team structure dictated to me
2. a working temporality scheme dictated to me
3. a geographic region in which I was allowed to hire
4. a headcount, position tuple I was required to abide by
I've come to regard these structures as weaknesses. It's a bit like the project management triangle in which you choose 1-2 from a list of inadequate options. Sometimes this is grounded in business reality, but more often than not it's because the people surrounding the decisions thrive on risk mitigation frameworks that become trickle down failure as they impose themselves on all aspects of the business regardless of compatibility.
At the moment, I'm in another startup that I have significantly more control over and again have found my partners discussing the imposition of structure and framework around how, where, why, who and what work people do before contact with any action. My mind is screaming at me to pull the cord, as much as I hate the expression. This stems from a single thought:
"Hierarchy and structure should arise from an understanding of a problem domain"
As engineers we develop processes based on logic; it's our job, it's what we do. Logic operates on data derived from from experiments, so in the absence of the real we perform thought experiments that attempt to reveal some fundamental fact we can use to make a determination.
In this instance we can ask ourselves the question, "what works?" The question can have a number contexts: people, effort required, time, pay, need, skills, regulation, schedule. These things in isolation all have a relative importance ( a weight ), and they can relatively expose limits of mutual exclusivity (pay > budget, skills < need, schedule < (people * time/effort)). The pre-imposed frameworks in that light are just generic attempts to abstract away those concerns based on pre-existing knowledge. There's a chance they're fine, and just generally misunderstood or misapplied; there's also a chance they're insufficient in the face of change.
Fictional entities like the "A Team," comprise a group of humans whose skills are mutually compatible, and achieve synergy by random chance. Since real life doesn't work on movie/comic book logic, it's easy to dismiss the seed of possibility there, that an organic structure can naturally evolve to function beyond its basic parts due to a natural compatibility that wasn't necessarily statistically quantifiable (par-entropic).
I'm definitely not proposing that, nor do I subscribe to the 10x ninja founders are ideal theory. Moreso, this line of reasoning leads me to the thought that team composition can be grown organically based on an acceptance of a few observed truths about shipping products:
1. demand is constant
2. skills can either be bought or developed
3. the requirement for skills grows linearly
4. hierarchy limits the potential for flexibility
5. a team's technically proficiency over time should lead to a non-linear relationship relationship between headcount and growth
Given that, I can devise a heuristic, organic framework for growing a team:
- Don't impose reporting structure before it has value (you don't have to flatten a hierarchy that doesn't exist)
- crush silos before they arise
- Identify needed skills based on objectives
- base salary projections on need, not available capital
- Hire to fill skills gap, be open to training since you have to pay for it either way
- Timelines should always account for skills gap and training efforts
- Assume churn will happen based on team dynamics
- Where someone is doesn't matter so long as it's legal. Time zones are only a problem if you make them one.
- Understand that the needs of a team are relative to a given project, so cookie cutter team composition and project management won't work in software
- Accept that failure is always a risk
- operate with the assumption that teams that are skilled, empowered and motivated are more likely to succeed.
- Culture fit is a per team thing, if the team hates each other they won't work well no matter how much time and money you throw at it
Last thing isn't derived from the train of thought, just things I feel are true:
- Training and headcount is an investment that grows linearly over time, but can have exponential value. Retain people, not services.
- "you build it, you run it" will result in happier customers, faster pivoting. Don't adopt an application maintenance strategy
/rant2 -
Dev: We have a data quality problem. Combined with data silos, we can't trust the numbers. We need to agree on metric definitions as a company.
CTO: (Points a PM)Help him on the metrics he has defined. We'll discard any other alternate definitions inside the company.
PM: You can start with these. (Throws a bunch of metrics without their definitions. Doesn't respond to questions regarding definitions.)
After a week of generating aggregates,
PM: The numbers seem wrong.
Fuck I know the numbers will be wrong. Because you didn't give me the definitions and I'll have to deduce them myself.
Seriously guys, how do you deal with PMs who don't cooperate in the requirement analysis?8 -
Devops is an HR/management wank-word.
Of course we all know that devops is a lean, next generation, best-practice, shifting focus towards actionable items to facilitate value added integration and synergy between two key silos of the company.2 -
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 -
How do I convince a dev department to take source control, peer code review and unit tests seriously?
I'm a recent software grad with internships that recently started at a smallish company (less than 20 employees but has been around for 10 years, with most senior non-mgmt employee around 6 years). I've been working here for less than a year (approx 5 months) and I love the company - lots of talented and passionate people.
We are a creative industry with a handful of devs and one of the issues I'm seeing is that often devs are working in silos. I'm trying to make suggestions to upper management like encourage more usage of source control, documentation, etc and most of the senior devs are pushing back - saying that they don't feel that it is necessary and due to the fast moving nature of our projects that all this would be a total waste (they were so fast on the idea of not having PR's because it would be "too much of a blocker").
I understand that a large part of this has more to do with shifting the culture in the department and that can be very hard to do, especially since i'm fresh out of school, but I see these devs have so much potential but it seems that they think having these implementations in place would mean more rigid rules and bureaucracy.
I've been speaking to some of my engineering friends and they're pretty much all just telling me that I am shooting myself in the foot if I continue to stay at this company because I'll be behind skill wise, but part of me isn't ready to just give up yet.
looking for some advice10 -
You join a new team. You find that the code is horrendous. Do you
A. Run away while in probation?
B. Start complaining about it and have the others hate you?
C. Cry silently and hope things will get better?9 -
One of our team mates is based out of the US office. We are physically distant, but after our manager's departure, we lost touch because our scope of work was different.
Me and two other team members work closely with each other from India and dude is alone, working out of the US.
Super smart, very polite, and a fun person to work and be with. Even when our interaction was less, I learnt so much from him.
Since, I am facing some challenges, I decide to use it as an excuse to connect with him for a coffee and also seek his guidance because he is senior to me.
Some things he mentioned,
1. Our new line manager asks him to do things on spot with no heads up. He has to drop everything and complete the ask.
2. Often times, poor guy, is asked to join meetings on immediate basis. Even while he is having his lunch.
3. He never got support from our new manager. Infact, based on the conversation, I realised that the manager supports me more.
4. He is facing same, if not more, issues with tech. And he didn't have any guidance on how to handle the issue.
5. A lot of times he is facing process and system problems which he isn't able to solve because the org culture is that of working in Silos. And he doesn't get any support from manager.
6. Tech has clearly pushed him back when he asked for help and other teams never respond to him.
My man was still smiling bright and was looking things from a positive lens that all of this is interesting and adds to the learning experience which will be valued when we decide to move on from this job.
These are the people who inspire me. Smiling in the time of adversity.
Even when he had his own challenges, he was ready to guide me and hear my frustrations. I offered him help and will make sure to stay connected so he doesn't feel left out and alone in the team only because we don't work together in physical space.
One thing I have learned over time is, while I am facing problems, someone out there is facing more and difficult problems then me. I always tend to blow up my problems out of proportion then what they actually are.
I am the dumbest person that I know and mark my words, I'll die because of my empathy. I wish I could help my team mate in any possible way.2 -
Nothing much here, keep scrolling...
I think my manager does not like me. I might sound like a broken record because I keep asking feedback at the end of every call (which is every other day).
I genuinely want to make her proud of the decision to hire me and want to learn for which I am willing to work smarter/harder.
What I feel is that they find me annoying. They seem to be happy with my work but guess my Indian roots of typical behaviour are showing up.
My co-worker evidently isn't confident to lead on her own and keeps me looped in to all her tasks which I am fine with. Though, I feel that I might be overstepping in her zone and manager doesn't want me to do that.
I may not be perfect and also a very sensitive guy, but I am trying hard.
Maybe they have plans to get someone else to lead and just keep me as a pawn on the board.
I don't think it is the imposter syndrome this time and surely the teams in this org are working in silos with very little communication within or outside their direct teams which kind of makes it even more difficult for me to operate.
However, as always, I have enough free time in here to resume my side project, learn another hobby, or learn new skills. Or is it just that I am assigned less task or underperforming?
Sometimes things are very confusing and one can never find an answer.
What's the best thing to do in such a situation?7 -
I hate when people just say "Hello!" in messaging apps and don't tell me what they want. Just ask me the question please! I might be in meetings and after 1-2 hours come back, reply, leave for another meeting and come back and the person hasn't asked the question yet...
-
Fuck you, you fucking fucks!
Brilliant idea #23 to deliver more features than can happen without a time machine.
Let's take the team, assume minimal support is required for the brand new thing you just built, split it into four teams with two of them run by Sr Devs who've never seen your app and work on four things in silos. That way, you'll deliver faster!
How did you even get you job?! You want to fucking wreck the team we worked so hard to build, convince the hot shots to leave, AND destroy the app the company is counting on because you're an incompetent fuck-tard!
Hey, fine! But you'll do it without me and I'll work daily to advertise what you did to the people above you that actually CARE about the fate of our company!4 -
What do you think of software architects? Do you believe that this role is needed in software development? Any good or bad examples?4
-
I’m a junior developer on a very small team (4 devs total including me and the manager).
Because we are so small, we work in silos. We individually work on issues and rarely work together.
There is a more senior dev that I really would like to work more with. I feel there is a lot to learn from him because he has the experience and skill sets that I would like.
What’s the best way to work with him more? Should I just ask him? Or is it better to find a more indirect way?7 -
Web, particularly the mobile web.
Why? I just found the concept of platform silos to be dumb. I want my creations to be experienced by as many people as possible. -
The Project Manager changed the project from scope driven to date driven with the teams giving him only t-shirt sizing estimates. Wish us luck...