> And devs need to take on more responsibility, broaden their non-technical skillset,
I've been trying to obtain more non-tech skills within various companies for years now, but I get nothing but more JIRA issues. At this point, I've come to the conclusion that the non-technical workers who deal with the business requirements, revenue, customer interaction, etc. do not want the tech folks to have any control over their domain.
What would they be needed for if we could do both the business functions and also write the code they depend on?
That's true. I think they're still needed in some capacity though, just in lesser quantities than is usual, and with more focus on supporting development and more of a quality over quantity approach. The devs shouldn't be doing everything (unless it's a really small team or a startup), but I find there's a strong tendency to go too far in the other direction. Managers love overhiring, either to mitigate risk, because of budget fuckery, or just because they've been conditioned towards a certain team make-up.
So what ends up happening is instead of having one designer that helps design the look and feel of the app, and sets the direction for the devs if they need help aligning their work to it; instead you have 3 or 4 designers that get pedantic about every pixel on the screen and insert themselves into every stage of development. It's not the designer's fault, there's basically nothing else they can do to fill out 40 hours a week.
This is the huge problem with overhiring, it's so easy to just generate more work to fill out your work week, and work begets more work (especially for the devs, who are usually the only ones actually 'producing' on the team, so work flows down to them). So what happens is as soon as your team goes above capacity in a certain area, it affects development. And once somebody is on the team, it's really hard to remove them from the team. That's just human nature. Which is why it's so important to grow a team slowly and naturally, measuring the effect on the team and gauging team member's opinions at each step of the process.
When I start a project I want to start it with 1-3 people, and do not just the high level planning, but establish roles within the team at a low level. What will we be delivering day to day and what is our capacity? Then once you've got that you can hire conservatively around that. The 'usual' way of forming a team within a big business is complete bullshit. You're making all the decisions up front and trying to read the tea leaves about what your project is going to look like in 6, 12 or 18 months.
I've been trying to obtain more non-tech skills within various companies for years now, but I get nothing but more JIRA issues. At this point, I've come to the conclusion that the non-technical workers who deal with the business requirements, revenue, customer interaction, etc. do not want the tech folks to have any control over their domain.
What would they be needed for if we could do both the business functions and also write the code they depend on?