Biggest productivity killers in the engineering industry

Lack of clear goals from the management.

Too many meetings, especially the recurring ones. Domination of spoken culture instead of written for collaboration.

Lack of proper sleep and rest. Working outside of your normal brain activity hours.

Sudden fire drills - "unforeseen" audit with deadline next Tuesday, a security vulnerability mentioned in TV and you needing to redeploy/upgrade everything ASAP.

I really hate every article from this site when they get posted. The advice is never really useful, and the authors strike me as the worst kind of micromanaging, ineffective leader to work under.

Kind of reads like leadership that wants to squeeze work out of people. At least some of your talent is going to need to think deeply to build actual systems, at some point, otherwise you’re just selling duct-taped together garbage. You CAN sell duct-taped together garbage, companies do it all the time— it’s not very interesting to work on though, hence your “unmotivated, lazy” engineers.

This is so different from what comes to mind when I think about how to improve productivity:

- require engineers to present and justify engineering investments (and understand that what you don't accept has real costs) - have engineers estimate the work in the roadmap, and provide clear risks and possible mitigations - note all of the above means the goals are clearly defined first - not everything you wanted to accomplish may fit; be prepared to distinguish essential from good to have, and to change the order of your priorities. - have teams commit to dates based on estimates, a healthy error margin, additional responsibilities, meetings... - plans change, things happen, life happens, engineering is hard. It's OK, it's expected! Make sure there are clear communication channels from engineers to the top, and from the top to the engineers, so that expectations are adjusted as soon as possible, and maybe make further adjustments. - Communication should happen often. Be always available to listen, don't micromanage. - managers should protect engineers and said communication channels - managers and PMs do not set deadlines - don't hire cheap; hire motivated team players. - the primary role of your >Senior engineers is to be force multipliers (how is a whole different conversation), not to do superhero work - communication, communication, communication; you'd be shocked how much time is wasted by engineers being unsure how to proceed and not sure who to ask of if the question will be well received; there are no bad questions.

I feel like I could go on and on and expand on many of these.

Yes: multitasking hurts; yes, procrastination is bad; but beyond looking at each "issue" individually, engineering leadership should provide processes and culture that protect, motivate and facilitate success.

Biggest productivity killers in the engineering industry:

#1 Hacker News

I feel like Slack is 80% of the problem. Honestly I'd like to get rid of it at our company, and just have everything come down/go back up through my manager. I realise some of you probably have never experienced this.

Mildly annoyed that the graph on "Perfectionism" has the time on the y axis instead of the x one...

A big one is keeping iteration times fast.. If you have to wait more than a few minutes to run through your test suite or deploy to a dev environment it really kills the momentum. It starts easy but as you add complexity, dependencies, slow or flakey tests, it is slowly gets eroded.

There has been so much research on this, and this article seems to ignore much of it.

The book Accelerate is a good start.

Oh we can’t just avoid context switching, can we? The way the company works is completely beyond the question. I should have to aggressively protect special “focus time” instead, because it’s my problem I have to solve.

> Biggest productivity killers in the engineering industry: eng-leadership (.com)

Funny how the domain name is the answer of the topic in question

Timeboxing is a pretty bad idea for the simple reason that it doesn't define the way to handle tasks that exceed the timebox. It simply assumes that tasks will take no longer than the timebox. Real life tasks don't work this way. In doing so, timeboxing closes the door to experiments, to discovery, and innovation.

Another one: "We're moving our stack to <flavor-of-the-month>."

or one that I lived through: "We're switching from SQL Server to Oracle." That one burned a few years that could have been spent on new features or improvements.

(everything is working with no effort)

No one:

IT infra: let’s move our repo platform to SaaS!

- Perfectionism, but defined as "Wanting to make things amazingly well, but never finishing them"

- Procrastination

- Issues from context switching and distraction

Is this ... ADHD?

Honorary mention:

SAFe agile

I wish the two axes in the perfectionism graph were swapped so all of the graphs will have time as the horizontal axis.

Slow edit refresh. When is say slow, I mean over 100 seconds.

> Let’s get back to this week’s thought!

Really made me laugh.

Solutions:

#1 get a private office

Scrum and Jira

Nitpic: I really dislike this trend of numbering x topics and then adding a "bonus" one. Just say it'll be 4 topics, please.

A trick from my PhD days: start the day with one to two hours of concentrated work. Don't look at your email or news or anything until you've done that.

This worked fabulously for me because it allowed me to "swap in" my work enough that I could avoid distractions.

And yes, I have ADHD.