4 ms·
<Rant> Is there any place in the world for a developer passionate about creating value for users and less so for fighting leadership-made fires (velocity! fast
by ThalesX 4y ago
<Rant>
Is there any place in the world for a developer passionate about creating value for users and less so for fighting leadership-made fires (velocity! faster! quicker!)? I don't care to debate endlessly about velocity and processes. I just want decently thought of processes, to adapt to them and produce value.
As an IC I don't want to be involved in every step of the strategy, to keep a track of all my colleagues and how they work, to keep track of the tasks in the context of the epics and the milestones, and be blamed for when a strategy I was not part of doesn't work. I don't want to answer "how could you do this faster?" for myself because it's a horrible question to have to answer almost every week when you feel like you're burning out running. I don't want to answer "what is the priority of the task you are working on relative to our investor's desires?" without actually knowing who the investors are. I don't want to have feel impostor syndrome every start of the week and be in a team that gets ground down at the end of every week for the shit job we're all allegedly doing and where solutions are expected to come from us.
I just wanna get to work, have a clear roadmap that was developed by CxOs, leadership, consultants, investors, people with actual domain knowledge, deeply thinking about what needs to be done and in what order (in order to produce value for our customers). Then I want to create a technical road-map with my fellow engineers and engineering leaders that takes into account business requirements, technical know-how inside the team, planning and start working on that, in sprints, under the watchful supervision of ... supervisors that don't need me to answer questions that they should have had the answers to about a half a year ago.
I'm feeling my mind closing down to this kind of stuff. I don't know how much longer I can do this. I am now in a position where on Monday I get a pile of unthought of requirements, by Wednesday everything changes. Thursday evening a fire starts burning and if fix is not done by Friday morning, we are already behind and disappointing our bosses and investors. Doing the fix and dropping the current task, for urgency, will of course get the velocity / scope discussion. And the seemingly simple fix for the entire team is apparently that we should just increase velocity, but we're just too retarded to do that.
A number of years ago, I left the corporate world, as horrible as that was, there were some people that had answers. Since joining the startup world, perhaps due to bad luck, I've never had a proper answer. I always get a "I'll get back to you on this" and they never get back. If I push for it, it usually gets deprioritized even though it was considered top priority. If I push even more I have to start investigating it. Talk to stakeholders that are not aligned on answers, and it never seems to be about users. It's always growth and velocity.
</Rant>
- morelandjs 4y agoI've been wondering for some time if it would be possible and effective to delegate all administrative and process responsibilities to line managers. Remove the IC from the planning documentation process entirely and let them plan their own execution however they see fit within each Sprint. The only responsibility for the IC would be stand ups with their manager to discuss progress and agree to future timelines. The ICs wouldn't have to go to any other Agile meetings or write any business/project planning docs. Manager would scope and write all IC tickets. I think you would very quickly see a culture change with regard to process work. Having sole responsibility for both creating and completing the process work, it would be in the manager's best interests to make it efficient. I've never seen an org try the above, but it doesn't seem crazy to me. I expect you'd still be able to attract managers through increased compensation and opportunities for career progression. Note: I'm not saying the IC forfeits all planning discretion, I simply mean it would be the manager's responsibility to write it up into whatever documentation is required by the org, track progress, rewrite the plan as necessary, etc.
- ThalesX 4y ago> The only responsibility for the IC would be stand ups with their manager to discuss progress and agree to future timelines. The ICs wouldn't have to go to any other Agile meetings or write any business/project planning docs. Manager would scope and write all IC tickets. I think this would end up causing negative feelings both for developers and managers. I've almost seen this in one place where we were Waterfall and it created a disconnect between the dev's understanding of the product, resulting in frustration and bad decisions (the small ones that you make during the day where it's important to have context of the product). The other interesting thing I noticed was that managers had a lot less excuses for the higher ups and would do a lot less office politics and a lot more execution, but that ended up also not working amazingly because we've had instances of people playing only politics and winning vs. execution (surprisingly fast to get promoted when instead of defining tasks and taking care of execution scheduling, you grab a coffee with your manager's manager) and that ended up frustrating managers also. At this point in my life I've given up on believing in both gajillion dollar corporate projects that mostly satisfy egos of stakeholders and startups that are not customer focused. I've also stopped believing in co-workers that are not user focused. I don't care both for how many mountains a manager can move, neither for the sacred 10x developer, if their talents are not put to use in the customer's name. And, to your post's subject, I've also stopped believing in any sort of process, that is not done to deliver more value to the customer. IMHO, your vision (or any other vision) could work, or not, depending on the people involved in the process.