This meets with my experience. I rarely have meetings, and I regularly get solid, 4-hour blocks of productivity. Typically two to three time per week. Those pushes account for most of my work, and my best work.
I do not schedule those 4 hour blocks because I would not be able to stick to the schedule. I often have trouble concentrating for even 30 minutes straight. When I hit 4 hours (and my time tracker sends me a notification to celebrate), I am always surprised. I get into the zone, and then I find myself still coding 4 hours later.
Every meeting is a chance to miss that enter-the-zone window.
I'm like this too, and I hate it - because it means I can't reliably get those four hour blocks.
Not having a schedule isn't a good thing, it just means that if you're ever in an environment where outside factors become significant (new job, new child), your productivity gets fucked.
I have the same issue. I'm managing a team, but at the same time I'm expected to actively participate toward the sprint goals. Because I keep getting pulled away for meetings, or to help the other developers, I can't get any focus time and my velocity is incredibly low. To the non-developers in my team, it seems like I'm a really slow developer and it's really hard to explain to them that it's really hard to write code ad-hoc.
<rant>
This has slowly and surely become the top reason for productivity loss at work for me and in my opinion, also for the team that I work in. I have walked out them once I realize there's no valuable input or output, declined them, carried my work in the meeting room, passively attended them, aggressively tried to keep the meeting on track, MoM'ed the hell out of them and just about tried every single trick I've known to get an ounce of productivity from them. And I have failed.
My next attempt is to measure time spent in meetings per sprint and report it out in the retro (meeting, ironically). I have no clue how I can get the people responsible for developer productivity see this gaping hole that are meetings that I don't have to be a part of.
</rant>
I took this to heart when it was published and ensured I schedule full team meetings that are as short as possible, and either start a day, end a day, or are directly adjacent to lunch. I also ensure there are 2 days of no scheduled meetings.
Another thing that helped me as an IC was keeping notes as a habit. It needs to become ingrained enough that it isn't blocking flow to jot a note into OneNote or Evernote. This allows you to 'see' the interruptions later.
I'm more of a 'pile' based note taker, so it's a gigantic list of timestamps + notes. If you are getting too many interruptions it also provides highly detailed 'proof' to the person in charge.
More recently I realized that getting distracted today is tremendously easier than it was in the past. When I find that is an issue I set a meditation timer to ring a bell every 5 minutes. If I'm not doing what I want to be doing when that bell goes off, I just go back to doing what I planned. At a certain point the bell ringing is just a habit to ensure your attention is in the right place.
I took over as IT Director at a company with a small team. Everyone would take their issues to the developer all day long, interrupting his day constantly. So every new "fire" because the latest task.
Not surprisingly the hacked together new website (which went live months late and $100s of Ks over budget) was a train wreck. Unreliable and constantly causing errors/issues.
The first thing I did was said the only person that can talk to the development team is me. It took about 2 months to get all the software processes in place that were non-existent, to get the entire website working and stable, and to get our task/goal list under control.
The cocksucker owner comes to me and says "I want these 4 project you quoted that would take 6 months done in the next 3 months". So I quit (so did their lead developer that was doing 90% of the heavy lifting).
IT Management is a mess everywhere I've ever been, just to varying degrees. Maybe this is because most my career has been as a consultant or contractor, but it's really discouraging.
I hope you didn't jump straight to quitting. There may have been a legitimate need to launch something that quickly. When I get requests like that, I usually explain the immutable rule of software development... deadline, quality, scope: pick two. Since he wants to adjust the deadline, ask him which of the other two he'll compromise. One answer, quality, would probably lead me to quit, since I can't stand delivering stuff that sucks, but if he were willing to adjust scope of those projects, it's a completely reasonable request.
I just wanted to share that I also had success setting a regular timer woth a short period: 3 minutes. If I do not notice the timer (it's just a small sound), then I am focused on my work. If I do hear i, then I realize that I am distracted and give myself 3 to 6 minutes (1 to two timers) of meditation or distraction, depending on what I feel I need at that moment.
Morning seems pretty common for stand-ups. Personally, I try to do my heavy cognitive tasks in the morning (so not a fan).
I think that some managers use morning meetings as a way to make sure people come in to work on the managers schedule.
Mornings are my “thinking” time.
The good idea/solution comes to me in the shower or while I’m sleeping and I drive to work thinking about it. I’m usually able to get a good start on implementing it before people can interrupt me.
My experience is that start-of-day meeting only works for a team of morning people or they all have kids. People show up at work at different times, and their day start at different times.
Reading the comments here I find it interesting how management totally ignores feedback from developers. A lot of devs think open offices and endless meetings are a drain on productivity. So you would think the reasonable response would be to address these issues to get as much productivity out of these often highly paid people but instead the top guys often do exactly the opposite. It's a very curious dynamic.
This is a constant trope, and every time it's wheeled out a bunch of developers say they would love more uninterrupted time and their own offices vs open spaces. Both of these ignore the obvious - you don't optimise on productivity locally you need to optimise on output of the system as a whole. Productivity of the system as a whole is significantly improved by communication. Devs in offices may burn through a ton of tickets very productively achieving failure by building the wrong thing.
Secondly, people who have never been managers often don't understand the externalities. As a manager, I've been asked "Why should the devs get so much better computers/bigger screens etc than us?" Different conditions can create an intense feeling of unfairness among people who don't get those conditions. Those types of things can wreck the culture at a company.
Finally, open space is much much more flexible, so easier to change up when you need people to sprint together on a thing, when you need to scale up your team etc. Offices are extremely inflexible and typically anchorpoints for people's perception of their own status. Therefore once someone has an office, it's practically impossible to get them to not have one any more, even if circumstances have significantly changed.
It's easy to blame management but it may well be that management have a totally different set of problems to consider than you.
The biggest problem with this argument is that the output of the system as a whole is not improved by open offices. It has all of the same problems that apply to productivity of individuals, with virtually no advantages. It’s a myth that communication is hindered by private offices, as much as managers or PMs want us to believe otherwise.
If devs are burning through tickets yet building the wrong thing, it’s not the office layout that is the problem. So having an open office environment while changing nothing else in that example simply means they are going to build the wrong thing much more slowly.
You are correct that it’s hard to come back to open space after having an office, but it isn’t for the reasons you mention. The reason is simply because open offices suck.
"Productivity of the system as a whole is significantly improved by communication."
That's an overly-generalized statement. Communication is sometimes helpful, when the people involved are good communicators. Often it's a source of distraction, e.g. email chains with multiple people replying-all to a topic that is at best tangential to what you're working on. There's also an equivalent that occurs with meetings in which people invite everyone they can imagine having any interest in a topic. This strategy has a wonderful way of bringing together a large number of people, most of whom have no valuable input, or interest, in the topic at hand.
The more detailed a job is, the more uninterrupted time it requires. So, if you want quality work and don't want to push the due date, give the person doing the work some uninterrupted time.
I've been a developer for 26 years professionally and, outside IT, I ran a 501(c)(3) of several hundred people. Yes, you can leave people alone to get work done without compromising organizational goals.
And most importantly, open space is cheap. None of the reasons you listed explain an open space containing 40 people working in different roles and teams, some of whom will never ever have a work related conversation.
This is a trope argument. You don't have to be connected at the hip with the rest of the company all the fucking time to make sure you are building the right thing. We are people, not cattle. You can instead do daily standups to make sure people are going in a direction you want. People (Management esp) who never get in the zone, don't fucking get it.
Status, envy, screen size - this is all bullshit. You have never been a good dev.
Sorry, but no. You don't deliver 'the wrong thing' because you're not interrupted constantly. One status check per day is enough to insure that. All the urgent communication that can't wait a day is ego-driven not results-driven.
Therefore once someone has an office, it's practically impossible to get them to not have one any more, even if circumstances have significantly changed.
What sort of change are you imagining which means someone should stop having an office?
Here’s a quick experiment. Tell your devs what you want. Get the hell out of their way. Identify the people and rituals that are ‘interrupting’ by nature and put in huge road blocks and obstacles between them and your devs. See and measure the difference in output. You will stay amazed.
You aren’t wrong about it being difficult to allocate resources so I can understand where you are coming from.
If it is a money problem, don’t lie to developers and tell them that it is “to encourage collaboration” i.e. don’t pee on my leg and tell me it’s raining.
If management truly believes in the collaboration meme, I fully expect them to share a big office. After all, what could be more important than having the gears of management fully meshed?
Either hire low skilled cooks to make your product and control them rigidly (like McDanals) or hire chefs. You can imaging how unhappy (!) a chef would be if you treated them like a Mcdonalds worker.
All true. And yet, management has to keep an eye on individual productivity, for at least two reasons. First, optimizing global productivity requires at least reasonable local productivity. And second, local productivity affects morale. You can lose your best people if they consistently feel unproductive.
It seems like ultimately, most senior managers don't care about feedback from developers.
They will ignore and steamroll any opinion that does not fit whatever arbitrary metric they need to meet, and when your dire predictions come true they will act like there was no possible way to expect them.
It's worse to have focused productive time on the wrong thing than it is to have meetings that clarify requirements and goals.
I've watched a lot of very highly paid people dive into deeply technical and interesting problems that nobody needed a solution to, and fight to protect their time so they could finish. That wastes more time and money than meetings.
Some of us are adult and have a professional attitude and don't need constant management. We know what needs to be done. We don't need to be treated like children.
The original article very clearly states that it discusses managers having to manage makers. Some of the jobs you described definitely don't seem to fit that description, so please don't hijack the discussion.
Also, not all teams have poor management. That you worked in the film industry where supposedly people had no idea of the priorities daily says nothing about the software industry in general.
My last several jobs involved sync meetings once every 5-10 days. Every meeting took 5 to 15 minutes and we all knew exactly what to do. Intermittent meetings only happened when somebody was blocked.
I've had success with an intermediate to a huge open office vs a private office which we called a lab, but might also be called a team room. We had about 6 people in there, all working on the same project, and it wasn't a constant distraction. We did a fair amount of pair programming as well, where a domain expert would sit with me as the computer scientist, and it was a very low bar to engaging in that sort of thing to slide around the corner. Of course we all had our own two person shared offices as well, but our main workstations were in the lab so most time was spent in there.
I agree that managers should very mindful of filling their teams' calendars with meetings. But there's not much a manager can do about open offices. They didn't design the building or the floorplan, and they can't change it now. Those decisions are made way above the typical managers' pay grade.
At my place, the people who book the meetings are the ones who are coordinating work done by others, so they need meetings to be productive. We have a product owner that is constantly justifying her existence by talking very much about things that have zero relevance to what we are doing at the moment.
I've tried to keep this top of mind for my team. It hasn't been perfect, but:
(every 2nd) Mondays - Planning
Tuesdays - some meetings for followups, sparingly
Wednesdays - NO MEETINGS ALLOWED (screaming intentional)
Thursdays - some meetings for followups, sparingly
Friday - NO MEETINGS ALLOWED (screaming intentional)
Works fairly well. There's a major increase in the amount of work done on W and F. However, going to three days without meetings didn't really help, as the problems we are working on do require lots of whiteboarding and brainstorming sessions between engineers.
I've found if the teams have mostly senior engineers there is very little need for meetings. In my current situation we just have one meetings per week to discuss status and priorities. Everything else is slack chats and adhoc meetings among individuals as needed. Mostly everyone is in sync on what is the right thing to do or if not, hash it out in a quick discussion.
That's how I love to work. We are adults and most of our workload is fundamentally adhoc, changing with our business partnerships and market fit. Unfortunately at my current job we squaded up adding extra meeting load anyone who works across squads. With weekly planning meetings and standups for every squad it's rough. Also people treat standups like they are free, why not add more? Well they are not. I have to fight being put on more than one. It's already one more than I would like anyway :)
I wrote an app called MakerSession [1] which was inspired by this essay. MakerSession automatically blocks out time on your (google or microsoft) calendar based on when your day starts/ends and how much time you need to get stuff done...
I've run a small distributed team for years, and I've mostly resolved the manager vs maker challenge through a combination of:
-desynced collaboration tools
-avoiding interruption based tools as much as possible
-short & focused bi-weekly meetings at the front or back end of the day
It allows the majority of the day for a maker schedule, while allowing for just enough manager time. Also with desynced tools (ex: outstanding support/bug/etc issues in Trello), as long as everyone is checking in at regular internals (say 2x a day) -- things can move through fairly quickly without constant interruptions.
For the manager side I use a mix of:
-Calendar/Contacts
-Evernote
-Workflowy
-Trello
-Slack (at scheduled times, leaving it on all day is horrible idea)
For the maker side:
-Workflowy
-Trello
-Pathjet.com (A small tool that I designed for myself which mixes GTD + Kanban + Pomodoro)
-Prior to my own tool, I used a Pomodoro timer + Workflowy on my machine
-Sometimes I think it's great to get off my machine, and just use a pen+legal pad to do planning/sketching/brainstorming
I have been parts of projects which failed just because the manager refused to accept that developers' need uninterrupted time to start and warm-up to achieve full speed in their daily routines.
Add micromanagement into this mix, and the environment quickly approaches to real-life-dilbert.
The problem I have now is; How can I get the manager to read, understand, and respect Maker Schedule?
Should I send them this link and then try to explain to them who Paul Graham is and why they should care about him? Should I send them the wikipedia article about Flow[1]? Should I show them the clip from The Social Network about "being in the zone"?
Maybe you should treat both schedules as equally valuable, while acknowledging the different purposes they serve, and respectfully discuss the problem with your manager to collaborate on a solution together. It could be as simple as "Please don't schedule meeting mid-day." When I was a 50% manager / 50% dev, I blocked off 10-2 forever on my calendar for my coding. Whatever you end up with, talk, don't send links -- sending links to articles comes off about as well as sending your fellow devs to LMGTFY.
They’ll agree because it’s reasonable and makes sense but the real test will be if they ask if they can book over that big maker block, just this once. And this once. And this project is really important so just this once.
It’s like technical debt. No manager is going to disagree that it’s important. But the test is if they ever make time for it or drop the story for something else.
Taking notes in a digital lab notebook (i.e. text file) while I'm thinking has sped up the re-inflation period significantly from ~1/2 hour to ~1-5 minutes.
I can highly recommend it for folks in very noisy/distracting environments. It also points out how much you struggle to stay focused if you are not continually writing in your notebook.
Unfortunately I'm not sure that explains it in any way that a non-maker would get. It's basically missing the last panel, where the dev writes a _new_ bug that costs millions of dollars because of the distraction.
Yes, all these things do help and you can also speak their language - they understand having multiple "back to back" meetings, so you if you schedule meetings with yourself, that you can't miss, and open up your schedule for other times, then you can allow them to book you then.
This is exactly what I learned after years of developing around meetings. Block your time first. And block your time based on your tasks you have to complete.
Sure you can't completely rewrite the billing system from scratch in an hour, but you CAN stub out the new architecture. Then each hour after that you fill in a method.
I feel needing 4-9 hour blocks of time means you AREN'T focusing, not that you are "IN THE ZONE"
Readit News
I do not schedule those 4 hour blocks because I would not be able to stick to the schedule. I often have trouble concentrating for even 30 minutes straight. When I hit 4 hours (and my time tracker sends me a notification to celebrate), I am always surprised. I get into the zone, and then I find myself still coding 4 hours later.
Every meeting is a chance to miss that enter-the-zone window.
Not having a schedule isn't a good thing, it just means that if you're ever in an environment where outside factors become significant (new job, new child), your productivity gets fucked.
People tend to start trying to work around the outside of those blocks.
<rant> This has slowly and surely become the top reason for productivity loss at work for me and in my opinion, also for the team that I work in. I have walked out them once I realize there's no valuable input or output, declined them, carried my work in the meeting room, passively attended them, aggressively tried to keep the meeting on track, MoM'ed the hell out of them and just about tried every single trick I've known to get an ounce of productivity from them. And I have failed.
My next attempt is to measure time spent in meetings per sprint and report it out in the retro (meeting, ironically). I have no clue how I can get the people responsible for developer productivity see this gaping hole that are meetings that I don't have to be a part of. </rant>
I like it because it's all automatic.
Another thing that helped me as an IC was keeping notes as a habit. It needs to become ingrained enough that it isn't blocking flow to jot a note into OneNote or Evernote. This allows you to 'see' the interruptions later.
I'm more of a 'pile' based note taker, so it's a gigantic list of timestamps + notes. If you are getting too many interruptions it also provides highly detailed 'proof' to the person in charge.
More recently I realized that getting distracted today is tremendously easier than it was in the past. When I find that is an issue I set a meditation timer to ring a bell every 5 minutes. If I'm not doing what I want to be doing when that bell goes off, I just go back to doing what I planned. At a certain point the bell ringing is just a habit to ensure your attention is in the right place.
Not surprisingly the hacked together new website (which went live months late and $100s of Ks over budget) was a train wreck. Unreliable and constantly causing errors/issues.
The first thing I did was said the only person that can talk to the development team is me. It took about 2 months to get all the software processes in place that were non-existent, to get the entire website working and stable, and to get our task/goal list under control.
The cocksucker owner comes to me and says "I want these 4 project you quoted that would take 6 months done in the next 3 months". So I quit (so did their lead developer that was doing 90% of the heavy lifting).
IT Management is a mess everywhere I've ever been, just to varying degrees. Maybe this is because most my career has been as a consultant or contractor, but it's really discouraging.
https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...
Mornings are my “thinking” time.
The good idea/solution comes to me in the shower or while I’m sleeping and I drive to work thinking about it. I’m usually able to get a good start on implementing it before people can interrupt me.
Secondly, people who have never been managers often don't understand the externalities. As a manager, I've been asked "Why should the devs get so much better computers/bigger screens etc than us?" Different conditions can create an intense feeling of unfairness among people who don't get those conditions. Those types of things can wreck the culture at a company.
Finally, open space is much much more flexible, so easier to change up when you need people to sprint together on a thing, when you need to scale up your team etc. Offices are extremely inflexible and typically anchorpoints for people's perception of their own status. Therefore once someone has an office, it's practically impossible to get them to not have one any more, even if circumstances have significantly changed.
It's easy to blame management but it may well be that management have a totally different set of problems to consider than you.
If devs are burning through tickets yet building the wrong thing, it’s not the office layout that is the problem. So having an open office environment while changing nothing else in that example simply means they are going to build the wrong thing much more slowly.
You are correct that it’s hard to come back to open space after having an office, but it isn’t for the reasons you mention. The reason is simply because open offices suck.
True, but in many cases, one good way to optimise the productivity of the system as a whole is exactly to optimize productivity locally.
Productivity of the system as a whole is significantly improved by communication.
Yes, but being in an office doesn't mean "no communication". Neither does being in an open environment guarantee effective, efficient communication.
Devs in offices may burn through a ton of tickets very productively achieving failure by building the wrong thing.
Same for devs in an open plan environment.
That's an overly-generalized statement. Communication is sometimes helpful, when the people involved are good communicators. Often it's a source of distraction, e.g. email chains with multiple people replying-all to a topic that is at best tangential to what you're working on. There's also an equivalent that occurs with meetings in which people invite everyone they can imagine having any interest in a topic. This strategy has a wonderful way of bringing together a large number of people, most of whom have no valuable input, or interest, in the topic at hand.
The more detailed a job is, the more uninterrupted time it requires. So, if you want quality work and don't want to push the due date, give the person doing the work some uninterrupted time.
I've been a developer for 26 years professionally and, outside IT, I ran a 501(c)(3) of several hundred people. Yes, you can leave people alone to get work done without compromising organizational goals.
Status, envy, screen size - this is all bullshit. You have never been a good dev.
What sort of change are you imagining which means someone should stop having an office?
If it is a money problem, don’t lie to developers and tell them that it is “to encourage collaboration” i.e. don’t pee on my leg and tell me it’s raining.
If management truly believes in the collaboration meme, I fully expect them to share a big office. After all, what could be more important than having the gears of management fully meshed?
Either hire low skilled cooks to make your product and control them rigidly (like McDanals) or hire chefs. You can imaging how unhappy (!) a chef would be if you treated them like a Mcdonalds worker.
Oh 2002 kicked quite a few asses out of offices and back into cubes.
They will ignore and steamroll any opinion that does not fit whatever arbitrary metric they need to meet, and when your dire predictions come true they will act like there was no possible way to expect them.
I've watched a lot of very highly paid people dive into deeply technical and interesting problems that nobody needed a solution to, and fight to protect their time so they could finish. That wastes more time and money than meetings.
Also, not all teams have poor management. That you worked in the film industry where supposedly people had no idea of the priorities daily says nothing about the software industry in general.
My last several jobs involved sync meetings once every 5-10 days. Every meeting took 5 to 15 minutes and we all knew exactly what to do. Intermittent meetings only happened when somebody was blocked.
(every 2nd) Mondays - Planning
Tuesdays - some meetings for followups, sparingly
Wednesdays - NO MEETINGS ALLOWED (screaming intentional)
Thursdays - some meetings for followups, sparingly
Friday - NO MEETINGS ALLOWED (screaming intentional)
Works fairly well. There's a major increase in the amount of work done on W and F. However, going to three days without meetings didn't really help, as the problems we are working on do require lots of whiteboarding and brainstorming sessions between engineers.
[1]-https://makersession.com
-desynced collaboration tools
-avoiding interruption based tools as much as possible
-short & focused bi-weekly meetings at the front or back end of the day
It allows the majority of the day for a maker schedule, while allowing for just enough manager time. Also with desynced tools (ex: outstanding support/bug/etc issues in Trello), as long as everyone is checking in at regular internals (say 2x a day) -- things can move through fairly quickly without constant interruptions.
For the manager side I use a mix of:
-Calendar/Contacts
-Evernote
-Workflowy
-Trello
-Slack (at scheduled times, leaving it on all day is horrible idea)
For the maker side:
-Workflowy
-Trello
-Pathjet.com (A small tool that I designed for myself which mixes GTD + Kanban + Pomodoro)
-Prior to my own tool, I used a Pomodoro timer + Workflowy on my machine
-Sometimes I think it's great to get off my machine, and just use a pen+legal pad to do planning/sketching/brainstorming
Add micromanagement into this mix, and the environment quickly approaches to real-life-dilbert.
Addenda: Obligatory dilbert: http://dilbert.com/strip/2018-04-21
Should I send them this link and then try to explain to them who Paul Graham is and why they should care about him? Should I send them the wikipedia article about Flow[1]? Should I show them the clip from The Social Network about "being in the zone"?
[1] https://en.wikipedia.org/wiki/Flow_(psychology)
It’s like technical debt. No manager is going to disagree that it’s important. But the test is if they ever make time for it or drop the story for something else.
I can highly recommend it for folks in very noisy/distracting environments. It also points out how much you struggle to stay focused if you are not continually writing in your notebook.
Sure you can't completely rewrite the billing system from scratch in an hour, but you CAN stub out the new architecture. Then each hour after that you fill in a method.
I feel needing 4-9 hour blocks of time means you AREN'T focusing, not that you are "IN THE ZONE"