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.
> Domination of spoken culture instead of written for collaboration.
I have sometimes wondered if this was just me. Glad to see it listed. I can’t count the number of times that “oh yeah, we talked about that and decided xyz” or “do you remember where we landed on abc in that meeting?” in a distributed environment.
I can’t force others to communicate about everything in writing, but I’ve learned to take detailed notes of my own thought processes and to write down everything important that happened in a meeting or conversation immediately after it finishes.
Meetings not degrading and wasteful enough? Make your employees also fill out a questionnaire and affidavit of a written summary of their potentially nuanced words to really move that morale needle!
Actually there is one way, which we use frequently at work and is quite effective. One of the participants has a screen shared and types in bullet points on topics and action points. In the final minute we just go over them and then as soon as the meeting ends the person presses send to all participants. Anyone not explicitly objecting shortly afterwards (which they wont because they just saw it being typed live and were asked again) would be tacitly confirming it. No extra hassle, and in fact less hassle.
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.
without trying to draw the line between designed systems and duct tape, this question of whether or not the organization is functional is far more important to me as a motivating factor than these other things. Do I fell like the quality bar is high enough that people will demand that I write adequate tests, or will they just wonder why I'm taking so much time. Does my work dovetail with other people's? Are they depending on me? Is this useful structure or just some ill-conceived minor feature request that I know is going to cause trouble later.
Does anyone actually care about what I'm doing, or are we just running out the clock.
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.
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.
I heavily agree. It’s something I had at my first office job. I had no email address, no messaging app, everything came through my PM or manager. Ive never been as productive as that job. Straight to work with no distractions and had clear goals.
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.
It takes over 30 minutes to run the entire test suite for our application on my local machine. Thankfully you can get it for under 20 minutes if you push it and have the CI test it for you.
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.
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.
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.
A therapist suggested this idea to me. Figure out when is your most productive time of the day (usually). Just two or 3 hours. OK, those are now your sacred hours. No procrastination or distractions allowed.
That can also work, unfortunately my most productive time tends to be at the end of the day. I find that what you start the day with sets the theme for the day.
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.