Hacker News Reader

Comment by madamelic | Hacker News Reader

> If you have nothing to show or demo after a 2 week sprint, during which you were surely assigned tasks to do, it's clear you haven't actually done anything.

Having just gotten out of a role like this: It's not.

It punishes doing backend / infra, tech debt, planning, or any work that isn't customer-facing (ie: stuff your senior+ engineers typically are expected to do). The demo day audience is largely non-technical people rather than it being a technical demo.

If you spent the sprint, or a large part of it, helping others or laying the groundwork for future projects with a company that treats demos like you've stated, you'll quickly push out anyone who is doing anything but blindly working on product.

I didn't leave / get pushed out because of the above, the cycle and meeting-heavy schedule drove me up the wall frankly.

View on HN

The thing to keep in mind is that many of these young startups, which likely includes the one from the OP, are built on the cloud/AWS. With AWS, there is no infra to manage like in companies of yesteryear; it's all abstracted away to AWS. In fact, at my current job, there doesn't even exist a "sysadmin" job role.

Additionally, I would argue that, especially if you are a senior+ engineer, not having anything to show after a 2 week sprint is a red flag and sets a poor example for junior engineers. Either you aren't meeting expectations for your role, or something is deeply wrong with how your company operates that prevents you from doing any real useful work day-to-day.

Expecting your senior engineers to be producing like exponentially or even linearly more work is not utilizing those engineers' expertise correctly, especially at a startup, in my opinion.

Seniors and especially higher should be expected to be spending some amount of their time on mentorship, helping others, creating/advancing product initiatives by planning or coordinating. If your product managers are flying solo with no input or even having non-technical managers dictate, that's worse than pulling seniors into some planning.

I've never had someone lay this out for me but my experience is there is a large chasm between senior and higher. Bridging that chasm generally doesn't come with increased individual technical output, it comes with utilizing others to advance projects with you.

That isn't to say senior+ can have no technical output all the time but I wouldn't be demo-ing an engineering RFC or new engineering initiatives at a demo day which will be consumed by other teams. Demo days aren't for the engineers or even product team; they already know what they did that week, I can go into version control or listen at standup.

I wonder if this is a misunderstanding on accountability. The demo days hold people accountable to others AND themselves.

There is a general movement to eschew accountability which is a huge mistake because this concept is critical in continuous improvement.

I don't understand how a senior developer partnering with juniors rather than crushing tasks solo equates to eschewing accountability -- especially if the goal is "continuous improvement" of the engineering org.

Although, it's not like the first time I've seen it expressed that senior engineers should outproduce juniors in terms of individual tasks/storypoints, and spend lots of time mentoring and pairing with juniors. Which I think is what you're getting at?

I disagree mightily with that. Those goals are in conflict and emphasizing individual stats is more or less the emperor of all perverse incentives. Instead, I favor the traditional agile/scrum emphasis on team velocity.

> With AWS, there is no infra to manage like in companies of yesteryear; it's all abstracted away to AWS.

I would argue that this is an extraordinary simplification. Infrastructure is abstracted away to the cloud vendor insofar as you don’t (typically) need to worry about power, physical connectivity to the host, logical networking at the layer of (for example) BGP, backup power, and so on.

But you absolutely have to concern yourself with infrastructure management to some extent. Be it backups, CI/CD infrastructure, BCDR management, geographic redundancy, proprietary vendor software that has prerequisites that your cloud provider doesn’t manage, OS patching for VMs, and so on.

Even if a business is 100% on a serverless stack for its service, it will still find itself with infrastructure to manage somewhere.

Some businesses have infrastructure because they need some type of interoperability to failsafe between clouds.

Even if a software business could succeed with no infrastructure of its own and no system administrators, that doesn’t have anything to do with tech debt. Tech debt can and does happen in any stack.

    especially if you are a senior+ engineer, not 
    having anything to show after a 2 week sprint 
    is a red flag

Is it? Couple of thoughts.

One: At agile/scrum shops where I've worked, it's the team who's responsible for completing goals and demoing and shipping. Not individual developers. So an IC having their own stuff to demo would be incongruous. (I believe this is official "Scrum" doctrine, not that I necessarily care because I'm not the biggest fan of Scrum)

Two: A senior engineer can optimize their time for crushing lots of solo work, or mentoring/collaborating with the junior devs. In that light, if a senior developer was racking up rockstar individual stats, I'd want to make sure that junior devs on their team are getting enough time and guidance.

I can think of countless exceptions to the above. Maybe you have a team comprised entirely of senior+ engineers and no juniors and there's no reason to really collaborate, so senior engineers should then of course be delivering.

Reply on news.ycombinator.com