Three-day no-meeting schedule for engineers(medium.com)
medium.com
Three-day no-meeting schedule for engineers
https://medium.com/@Pinterest_Engineering/three-day-no-meeting-schedule-for-engineers-fca9f857a567
187 comments
I got to work for a few years with pivotal labs in the Bay Area. They had a policy called “just don’t have f&$@ing meetings.” At first I thought this was a bit crazy. How could we work without meetings? Then I realized that product owners, actual 10 minute stand ups, and a 30 minute weekly planning meeting was all we really needed to make amazing products. I’ve keep that philosophy ever since and it has worked very well in big and small organizations.
Pivotal is clearly a style that works well for some people. But couldn’t you categorise the constant pairing as a form of ongoin meeting? It doesn’t seem like the place to go if you want to be left alone...
I absolutely agree with you that it is not the sort of place you want to go if you'd like to be left alone. No doubt there. However, I would say that constantly pairing really is nothing like an ongoing meeting either. A really good paired programming environment, if you like that sort of thing and work well in that sort of environment, is very effective for writing and deploying fantastic products and features. I find meetings are very not effective for writing and deploying fantastic products and features.
I'd really rather not say there is a "Pivotal" style as much as an Extreme Programming paradigm. Extreme Programming says that an environment is better when you work normal hours. It states that an environment is better when there are fewer meetings. It states that an environment is better when you try paired programming, test driven development, continuous processes, simple design, good communication, etc etc etc. I think all of these things are very good. I also believe a few of these principles don't work well for specific individuals. There are principles that effect the business (fewer meetings, sustainable pace, continuous practices). So far I have always seen those principles as good. There are also principles that effect the individuals (paired programming, test driven development, close proximity for communication). I have seen those not work well for some individuals and should be adjusted to your individual employees.
I'd really rather not say there is a "Pivotal" style as much as an Extreme Programming paradigm. Extreme Programming says that an environment is better when you work normal hours. It states that an environment is better when there are fewer meetings. It states that an environment is better when you try paired programming, test driven development, continuous processes, simple design, good communication, etc etc etc. I think all of these things are very good. I also believe a few of these principles don't work well for specific individuals. There are principles that effect the business (fewer meetings, sustainable pace, continuous practices). So far I have always seen those principles as good. There are also principles that effect the individuals (paired programming, test driven development, close proximity for communication). I have seen those not work well for some individuals and should be adjusted to your individual employees.
Is it fair to say no remote teams were involved & most people sat close together?
At Pivotal Labs, yes. However, I work in a completely remote environment right now. We have an office for the business but no one in the product engineering teams or tech teams work in the office (or even in the same state or country as the office). We have a written daily roundup (like a 10 minute standup but it's written and it's asynchronous), a 30 minute retrospective once a week, and a 30 minute planning meeting once per week. That is the grand total of all meetings for the group as a whole. Individuals may meet and work together as needed. It works extremely well for remote work.
> We have a written daily roundup (like a 10 minute standup but it's written and it's asynchronous)
How does this help with discovery of issues that other folks on the team may have experience/suggestions solving? I.e. do you require everyone to read the daily round up?
How does this help with discovery of issues that other folks on the team may have experience/suggestions solving? I.e. do you require everyone to read the daily round up?
To be frank, I expect people to work as a team. I expect that people will read the daily round ups, yes and they do. We do have closer to synchronous communication channels (Slack) which people can reach out on for help. And they absolutely do all the time. Our teams members are quite close and are very willing to say when they have a problem and to help one another when they can with problems.
We have an absolutely open environment. It's a side effect of our process.
We have an absolutely open environment. It's a side effect of our process.
It sounds like the meetings are compressed into the other two days of the week, which also sounds quite miserable.
I'd love to see an app that analyzes the internal meetings that happen inside a company and flags the repeat offenders. I've always found that a small percentage of people hold the most meetings. It also can be a bit awkward to reject their meeting invites constantly.
Leaders should remind people about the time-cost of meetings (here's a calculator to help: https://hbr.org/2016/01/estimate-the-cost-of-a-meeting-with-...). There are meetings that can be beneficial for alignment, but then there are the reoccurring ones where people just want to know what you're working on.
Anyways, I'm working on a tool to help cut down on the "what's going on" meetings: https://www.fridayfeedback.com
I'd love to see an app that analyzes the internal meetings that happen inside a company and flags the repeat offenders. I've always found that a small percentage of people hold the most meetings. It also can be a bit awkward to reject their meeting invites constantly.
Leaders should remind people about the time-cost of meetings (here's a calculator to help: https://hbr.org/2016/01/estimate-the-cost-of-a-meeting-with-...). There are meetings that can be beneficial for alignment, but then there are the reoccurring ones where people just want to know what you're working on.
Anyways, I'm working on a tool to help cut down on the "what's going on" meetings: https://www.fridayfeedback.com
The compression is surely miserable to start, but I hope people stick with it to see what happens next.
In Lean Manufacturing, a common process improvement technique is to tighten some constraint. E.g., if you normally have 10 boxes of parts in play, you drop it to 9 and see what happens. Probably something will happen, as they ended up at 10 for a reason. But then you consciously solve issues until 9 is as smooth as 10. The metaphor they use is ships in channels: if you lower the water level a bit, it will expose rocks, which you remove. Then you lower the water level a bit more.
My guess is that if these teams are doing weekly retros, they'll feel the pain of compression. People will then brainstorm ways to make the least useful meeting unnecessary. Or to make a longer meeting shorter, and therefore more efficient. First they'll start with the easy things, but eventually they may move on to rearranging workflows, cross-training, and maybe even swapping people among teams.
It's really weird to me that in office-work meetings take priority over direct value-generating work. Compare that with a factory floor or a restaurant, for example, where everybody gets that it's bad to randomly stop direct productivity. Hopefully having clear time constraints will help reverse that.
In Lean Manufacturing, a common process improvement technique is to tighten some constraint. E.g., if you normally have 10 boxes of parts in play, you drop it to 9 and see what happens. Probably something will happen, as they ended up at 10 for a reason. But then you consciously solve issues until 9 is as smooth as 10. The metaphor they use is ships in channels: if you lower the water level a bit, it will expose rocks, which you remove. Then you lower the water level a bit more.
My guess is that if these teams are doing weekly retros, they'll feel the pain of compression. People will then brainstorm ways to make the least useful meeting unnecessary. Or to make a longer meeting shorter, and therefore more efficient. First they'll start with the easy things, but eventually they may move on to rearranging workflows, cross-training, and maybe even swapping people among teams.
It's really weird to me that in office-work meetings take priority over direct value-generating work. Compare that with a factory floor or a restaurant, for example, where everybody gets that it's bad to randomly stop direct productivity. Hopefully having clear time constraints will help reverse that.
People exhausted by all day meetings aren’t in a good mental space to solve the problem (often the retro is at the end, after all, when everyone wants to just gtfo)
Hi, I’m a project manager. I’m the guy who is likely scheduling most of those meetings. Nice to meet you!
I think, by and large, we understand the cost of meetings, and don’t casually organize them without going through the alternatives. It’s not rocket science. My thought process is generally:
0. Before anything, come up with a written agenda and goals for the communication. Don’t move past this step until done.
1. Does this communication even need to happen? Maybe there is an internal document already I can point people to.
2. If not, Can this be done async over E-mail?
3. If not, can it be done over chat?
4. If not, can it be done in a series of 1:1s between me and each attendee?
5. If not, then a meeting has to happen. What’s the true minimal list of required attendees? Who is optional? I am loathe to waste the time of a productive individual contributor if I don’t have to. If I can invite his/her manager instead, I will. Sorry, that’s the Faustian bargain you make when becoming a manager!
6. What’s the shortest possible productive duration?
7. Is there a time slot that is miraculously free for everyone, respecting time zones and working hours for people?
8. If not, is there a time slot that works for most people?
If, again by some great miracle, there are multiple time slots that work, I favor ones that are adjacent to other meetings in their calendars, so as to not break up a productive no-meeting block.
I think, by and large, we understand the cost of meetings, and don’t casually organize them without going through the alternatives. It’s not rocket science. My thought process is generally:
0. Before anything, come up with a written agenda and goals for the communication. Don’t move past this step until done.
1. Does this communication even need to happen? Maybe there is an internal document already I can point people to.
2. If not, Can this be done async over E-mail?
3. If not, can it be done over chat?
4. If not, can it be done in a series of 1:1s between me and each attendee?
5. If not, then a meeting has to happen. What’s the true minimal list of required attendees? Who is optional? I am loathe to waste the time of a productive individual contributor if I don’t have to. If I can invite his/her manager instead, I will. Sorry, that’s the Faustian bargain you make when becoming a manager!
6. What’s the shortest possible productive duration?
7. Is there a time slot that is miraculously free for everyone, respecting time zones and working hours for people?
8. If not, is there a time slot that works for most people?
If, again by some great miracle, there are multiple time slots that work, I favor ones that are adjacent to other meetings in their calendars, so as to not break up a productive no-meeting block.
Good job there with your checklist. Unfortunately, for every one of you who does the above checklist before pulling the "schedule meeting" trigger, there are 500 other project managers who's first reaction to everything is: "schedule a meeting".
Then there is the "I can get what I need in a 2hr meeting at the cost of 16hrs of other peoples time" ones.
I hate those ones.
If your programmers are taking laptops to meetings to write code while you are holding the meeting, you should consider a career in yak-farming not project management.
Also we need to schedule a meeting to find out why we are behind on our deliverables because of last weeks meeting taking most of the day putting everyone behind.
That one made me giggle.
Or as one of my friends at that place had as a wallpaper "The beatings will continue until morale improves".
I hate those ones.
If your programmers are taking laptops to meetings to write code while you are holding the meeting, you should consider a career in yak-farming not project management.
Also we need to schedule a meeting to find out why we are behind on our deliverables because of last weeks meeting taking most of the day putting everyone behind.
That one made me giggle.
Or as one of my friends at that place had as a wallpaper "The beatings will continue until morale improves".
There are lots of terrible meeting formats. There’s the “everyone talk about what they are not doing because they’re meeting to talk about it” aka Daily Standup. There’s the Bug Beatings, where 50 people gather to go through 200 open bugs, each one where 1 (different) person talks and the remaining 49 work on their laptops. There’s my least favorite: I call it “Executive Storytime” where multiple people put together a status update for a big-shot, and instead of big-shot reading it himself, we project it and read it to him. This is ok when the format is meant to be interactive but if it’s just a readout—yukk. Then there’s the Agendaless Sync, where the same people get together weekly because they always get together weekly and just talk about whatever. Ugggghh.
These days I'm the only programmer at a none-tech company and it's glorious, I answer directly to the MD.
I set my own schedules, timelines, I prioritise bugs and maintenance and I handle buying anything we need as well having complete freedom in the technologies I choose to solve problems (currently moving to TypeScript for front end stuff for example) - his attitude is to hire good people across the business and then get out the way as much as possible.
The boss sets overall goals and we agree together on what is achievable in a given time period.
Honestly my job has made me remember what it was I loved about programming (solving real world problems that have a measurable impact).
Even the fact I inherited the worst codebase I've ever seen doesn't get me down because my boss knows how bad it is (it's why he got rid of the outsourced company and hired a programmer in house) and I get to work on a bunch of cool problems (production scheduling in a varied environment, global logistics (we import from China and India), some C# stuff (production control), Android (inventory control, scanners)).
I actually get to 5pm and want to keep working but the boss bollocks me if I stay late (even though he does most days).
I'd have to be offered a spectacular pay rise to even consider working for a 'tech' company again.
I set my own schedules, timelines, I prioritise bugs and maintenance and I handle buying anything we need as well having complete freedom in the technologies I choose to solve problems (currently moving to TypeScript for front end stuff for example) - his attitude is to hire good people across the business and then get out the way as much as possible.
The boss sets overall goals and we agree together on what is achievable in a given time period.
Honestly my job has made me remember what it was I loved about programming (solving real world problems that have a measurable impact).
Even the fact I inherited the worst codebase I've ever seen doesn't get me down because my boss knows how bad it is (it's why he got rid of the outsourced company and hired a programmer in house) and I get to work on a bunch of cool problems (production scheduling in a varied environment, global logistics (we import from China and India), some C# stuff (production control), Android (inventory control, scanners)).
I actually get to 5pm and want to keep working but the boss bollocks me if I stay late (even though he does most days).
I'd have to be offered a spectacular pay rise to even consider working for a 'tech' company again.
And the always wonderful - meeting that should have been an email.
https://imgur.com/gallery/9yF0Vyo
https://imgur.com/gallery/9yF0Vyo
Sounds like a good thought process, but that's not how I feel it happens in my department. The thought process there is more like "hey, this sounds like it's relevant for 'the team'. Let me check the calendar for the first open slot!"
Maybe it’s old but you need to read manager vs maker schedule:
http://paulgraham.com/makersschedule.html
It is the gold standard on why creative workers hate meetings. All those things you mentioned sound great, but you’re still destroying productivity if you’re scheduling meetings anywhere other than the immediate beginning or end of the day.
For makers, there are only 2 time slots: before lunch and after lunch.
For makers, there are only 2 time slots: before lunch and after lunch.
> and don’t casually organize them without going through the alternatives
I'm routinely asked to join after-hours deployment calls that last hours and which my contribution is minimal, "just in case". You may not be casually organizing them, but there are plenty out there who are.
I'm routinely asked to join after-hours deployment calls that last hours and which my contribution is minimal, "just in case". You may not be casually organizing them, but there are plenty out there who are.
This is a great checklist! Do you have it posted in "blog post" format somewhere for posterity?
These would be great questions to answer when creating an event invite. Would make a pretty useful chrome extension.
You sound like a great pm any thoughts to transferring your system into a package for other pm's?
I much prefer meetings to get compressed together as much as possible. If I'm going to get ripped out of my context for a meeting, I'd rather take that hit only once and carry it into as many meetings as possible.
> It sounds like the meetings are compressed into the other two days of the week, which also sounds quite miserable.
True, but it forces meetings to compete with meetings rather than development in the schedule.
True, but it forces meetings to compete with meetings rather than development in the schedule.
This is actually a very acute and non-obvious observation. People might get tired during meetings, but this will mostly affect following meetings, rather than engineering. And it's easier to focus on an activity (and optimize it) if it lasts a day rather than an hour. This might end up improving the overall "meeting culture" in the company, teaching people to schedule breaks, be on time and so on.
For a while, I worked mostly remote, four days at home, one day in the office. I miss those days badly... I've never been more productive. Scheduling all the in-person meetings and status updates and planning work into the Monday in the office was the key. Embrace the suck, and the fact that no work will be done that day - you never get any real work done on a Monday anyway, and once you're into status meetings, it's all over anyway. But doing all of that planning and collaborating and getting the shit together on Monday meant the week was laid out, and Tuesday through Friday were freed up for big blocks of deep work. Bonus, not being physically in the office meant I was out of sight and out of mind, free to actually get some work done.
> It sounds like the meetings are compressed into the other two days of the week
That was my first thought, too. I was talking once to a guy who was hiring for a developer position that he couldn't get filled - he told me that he was sweetening the deal by ensuring the dev candidates that they wouldn't have to attend any meetings; he would attend all the meetings for them so they could focus on coding. I had a sneaking suspicion that they realized what he didn't realize... that they'd be on the hook not only for implementing everything that was discussed in these meetings but also interpreting them through him.
That was my first thought, too. I was talking once to a guy who was hiring for a developer position that he couldn't get filled - he told me that he was sweetening the deal by ensuring the dev candidates that they wouldn't have to attend any meetings; he would attend all the meetings for them so they could focus on coding. I had a sneaking suspicion that they realized what he didn't realize... that they'd be on the hook not only for implementing everything that was discussed in these meetings but also interpreting them through him.
Just a heads up, fridayfeedback has some layout issues for me: https://i.imgur.com/DdevMCy.png
This is on Chrome 66.0.3359.139, Windows 10, fullscreen on a 1920x1080 screen. I get the same layout issue in Firefox.
This is on Chrome 66.0.3359.139, Windows 10, fullscreen on a 1920x1080 screen. I get the same layout issue in Firefox.
Meeting # 1: How many images can we fit on the page?
Meeting # 2: No seriously, how many more images can we fit on the page?
Same meeting every week at pininterest
Meeting # 2: No seriously, how many more images can we fit on the page?
Same meeting every week at pininterest
Hahaha, meetings on my team at Pinterest are a little more substantial than that, but maybe it varies team to team?
"Can you join a call to talk about how many images we can fit on a page? I know it's 9 PM, but we'll time-box it so the call lasts no later than 1 AM"
Maybe I'm off base here, but to me, meetings are not nearly as big a disruption to my IC work as random interruptions from teammates. Meetings are usually planned and able to be worked around and scheduled for. There is typically an agenda, and if there isn't, it's very simple to ask for one. If it's not valuable, don't go, or leave. If you must go, you can often get the meeting rescheduled - people in engineering organizations are surprisingly accommodating of the maker's schedule.
A random interruption by an engineer when you're trying to focus is much more disruptive because it's unplanned and often pulls you right out of the zone. Often times, especially for more senior engineers, an enormous amount of patience has to be practiced as you listen to someone ramble on as the context in your head flutters away, while they go in circles explaining the problem to themselves.
This is all part of the job though. People don't have all the answers and the questions are often poorly defined. My skills wouldn't be nearly as valuable if the problems were so cut and dry that I could just program a solution straight through without interrupting anyone for clarity. I don't quite get the hang wringing over being interrupted. It happens, and it happens especially more as you get more senior. Some of the best solutions to problems I've come up with have not been technical, but have come about by talking to people and realizing that maybe the technical solution we were pursuing wasn't the best one, and we could save a lot of time and money by solving the problem a different way.
A random interruption by an engineer when you're trying to focus is much more disruptive because it's unplanned and often pulls you right out of the zone. Often times, especially for more senior engineers, an enormous amount of patience has to be practiced as you listen to someone ramble on as the context in your head flutters away, while they go in circles explaining the problem to themselves.
This is all part of the job though. People don't have all the answers and the questions are often poorly defined. My skills wouldn't be nearly as valuable if the problems were so cut and dry that I could just program a solution straight through without interrupting anyone for clarity. I don't quite get the hang wringing over being interrupted. It happens, and it happens especially more as you get more senior. Some of the best solutions to problems I've come up with have not been technical, but have come about by talking to people and realizing that maybe the technical solution we were pursuing wasn't the best one, and we could save a lot of time and money by solving the problem a different way.
I usually find adhoc interruptions are due to someone being blocked and spending 5 minutes with them can really turn their next few hours around. It's good for the team as a whole. Meetings on the other hand are minimum 30 minutes and usually involve half a dozen people. The bang for buck on interruptions is way higher than meetings.
At my current job I have about 10-15 meetings every week, and I'm an IC. It drives me crazy. I feel like I have to fight tooth and nail to get time to work on the project I'm assigned to.
At my current job I have about 10-15 meetings every week, and I'm an IC. It drives me crazy. I feel like I have to fight tooth and nail to get time to work on the project I'm assigned to.
This depends very much on your position and the structure of your company. 5 minutes is fine if you're getting one a day. If you have dozens of ad-hoc interruptions every day, you're getting interrupted for hours. Placing these interruptions randomly throughout the day means you don't have any solid blocks of time in which to get work done.
This is one of the reasons that your best engineer should be on the least important project: everybody knows he can answer your complex questions fast, and they know what he is doing isn't very important so even if it can be definitively proven that your interruption caused his project to be late nobody will care.
Why would your best engineer stay at your company if they're given unimportant projects and treated as tech support for your worst engineers?
I suspect it would be better worded as 'least urgent' project. Some of the most interesting projects I've done have been long-term things that didn't need to make it out for 6 or more months, and really only needed a month to implement - but they did really need to make it out at the end of those 6 months.
With things like that, though, you can a) pull the engineer off for truly urgent 'done by Friday or we lose the customer(s)' issues, and b) losing some time due to interruptions isn't really world ending. For (a) to work you'd also probably want to stop having them interrupted.
With things like that, though, you can a) pull the engineer off for truly urgent 'done by Friday or we lose the customer(s)' issues, and b) losing some time due to interruptions isn't really world ending. For (a) to work you'd also probably want to stop having them interrupted.
That was how I was treated for the last year or so. It's not good for morale or retention. Even if I'm working on something that doesn't have a deadline, I still want to get work done every day. I'm not tech support and I won't stay in a position where that's my job.
Unimportant to the business is not the same is unimportant for other purposes. There are a lot of unimportant projects that are interesting to an engineer.
Trying all the latest javascript framework is not important to the business, but but is your best person is free to try each fad, every once in a while he will be able to say "this one isn't just a fad we should use it". It is thus important for someone have time to do this.
Trying some new tool is not important, but it might long term result in better quality if the tool turns out useful.
Upgrading the CI system might not be important, but if you let it fall out of date you get into trouble.
Stepping back from the day to day schedule allows the best engineer to focus thinking up a better solution. There are many things that are done "because we have always done it that way", but in fact the pressures of a 8-bit CPUs and limited memory 40 years ago drove that decision and there is a better way that modern CPUs could do now if only people weren't blinded by how it has always been done. The proof of concept will get management excited enough to make this the number one project, but right now they can't imagine the better way is even possible. (and the best engineer will sometimes discover the algorithm isn't actually possible)
In short the unimportant projects the best engineers work on should be largely self directed. There is the following items that are a consideration so long as they don't take up too much time. (if they add up to 25% you need someone assigned to that problem)
The best engineer is also free when a customer discovers a show stopper bug. If it is easy he can get the fix done in a couple days without interrupting the main team.
The best engineer is free to tell marketing which ideas are possible and which is impossible. He can also help workout timelines. Thus ensuring that the next project is actually possible in the time given.
The best engineer is there when sales says "I could make this big sale if only we had feature..." - some of those features can be done in a few hours and make a lot of money. Others take years and lose money - but the salesman has someone to ask before making a promise that cannot be met (that doesn't mean the saleman will ask)
This is also a rotation - your second best developers will be playing "leapfrog" to the best and then your best developer gets rotated into a valuable assignment while the new best engineer gets to lead a project again.
If your company has any size to the engineering team you can find those engineers who are self directed who will enjoy the lest important project
Trying all the latest javascript framework is not important to the business, but but is your best person is free to try each fad, every once in a while he will be able to say "this one isn't just a fad we should use it". It is thus important for someone have time to do this.
Trying some new tool is not important, but it might long term result in better quality if the tool turns out useful.
Upgrading the CI system might not be important, but if you let it fall out of date you get into trouble.
Stepping back from the day to day schedule allows the best engineer to focus thinking up a better solution. There are many things that are done "because we have always done it that way", but in fact the pressures of a 8-bit CPUs and limited memory 40 years ago drove that decision and there is a better way that modern CPUs could do now if only people weren't blinded by how it has always been done. The proof of concept will get management excited enough to make this the number one project, but right now they can't imagine the better way is even possible. (and the best engineer will sometimes discover the algorithm isn't actually possible)
In short the unimportant projects the best engineers work on should be largely self directed. There is the following items that are a consideration so long as they don't take up too much time. (if they add up to 25% you need someone assigned to that problem)
The best engineer is also free when a customer discovers a show stopper bug. If it is easy he can get the fix done in a couple days without interrupting the main team.
The best engineer is free to tell marketing which ideas are possible and which is impossible. He can also help workout timelines. Thus ensuring that the next project is actually possible in the time given.
The best engineer is there when sales says "I could make this big sale if only we had feature..." - some of those features can be done in a few hours and make a lot of money. Others take years and lose money - but the salesman has someone to ask before making a promise that cannot be met (that doesn't mean the saleman will ask)
This is also a rotation - your second best developers will be playing "leapfrog" to the best and then your best developer gets rotated into a valuable assignment while the new best engineer gets to lead a project again.
If your company has any size to the engineering team you can find those engineers who are self directed who will enjoy the lest important project
Because you pay them well and give them credit for all the projects they contribute to, even as an occasional consultant.
That's a very nice way to look at it but you're talking about a good engineer that's been with the company for a while to prefer mentoring others over just working on whatever they want.
Answering random on-demand questions isn't the same as mentoring. In order to mentor people, you need to be given long-term leadership roles where you work closely with a small number of people.
Re: meeting length. I started scheduling 15 minute calls and it caught on. With a pre-circulated agenda and the usual 5 mins to get everyone onto the WebEx it was quite effective
"We only have 10 mins so let's get to the point"
"We only have 10 mins so let's get to the point"
> I usually find adhoc interruptions are due to someone being blocked and spending 5 minutes with them can really turn their next few hours around.
I've found polling to be a good way to handle this while avoiding the problems of being interrupted yet still being reasonably responsive to coworkers needing help.
I take a short break every 20-30 minutes to avoid health problems from sitting too long [1]. Those breaks are a perfect time to check email and chat for requests for help.
My notifications are set so that when I get an email or chat I get a banner for a few seconds in a corner. If one comes in while I'm in the zone, I can assess it without losing flow because I know I've got a break coming up soon, and so I only have to decide if the incoming message is so important it can't wait for the break.
[1] http://ergo.human.cornell.edu/cuesitstand.html
I've found polling to be a good way to handle this while avoiding the problems of being interrupted yet still being reasonably responsive to coworkers needing help.
I take a short break every 20-30 minutes to avoid health problems from sitting too long [1]. Those breaks are a perfect time to check email and chat for requests for help.
My notifications are set so that when I get an email or chat I get a banner for a few seconds in a corner. If one comes in while I'm in the zone, I can assess it without losing flow because I know I've got a break coming up soon, and so I only have to decide if the incoming message is so important it can't wait for the break.
[1] http://ergo.human.cornell.edu/cuesitstand.html
> My notifications are set so that when I get an email or chat I get a banner for a few seconds in a corner. If one comes in while I'm in the zone, I can assess it without losing flow because I know I've got a break coming up soon, and so I only have to decide if the incoming message is so important it can't wait for the break.
I get those notifications on my phone, so I just keep my phone face up next to my computer, so I can easily glance at the notifications, but I'm less tempted to respond.
I get those notifications on my phone, so I just keep my phone face up next to my computer, so I can easily glance at the notifications, but I'm less tempted to respond.
I've never had this work in a cube-farm. It is apparently too easy to just assault you in person, even when you are obviously deeply concentrating.
Holy shit, I’m a product owner and I don’t have nearly as many meetings as that. How many bosses do you have?
The individual meetings aren't a big interruption on their own, but their scheduleing is usually the problem. I frequently will have half hour meetings in a day but sprinkled throughout the day, which means I am always just getting back into the zone when trying to work.
When you combine that with coworker interruptions and the need to eat I can end up with an entire day where I can't solve anything more than trivial problems.
I can always stay late or work on the weekends but I don't really have any desire to eat into my free time because management wants to constantly hear updates from me every day about how the very work they are interrupting is going
When you combine that with coworker interruptions and the need to eat I can end up with an entire day where I can't solve anything more than trivial problems.
I can always stay late or work on the weekends but I don't really have any desire to eat into my free time because management wants to constantly hear updates from me every day about how the very work they are interrupting is going
Have you tried telling management that them asking for updates is slowing the work down? You can't expect them to read your mind.
I find it easier to just block off 4 hour chunks of my day as a way to convey: I'm only working during these times no meetings. In manager land a block of free time is fair game, so play by those rules and make your own meeting with work.
When any manager asks why you just tell them and explain. Seems to work fine.
When any manager asks why you just tell them and explain. Seems to work fine.
The people calling the meetings don't have any of their goals tied to engineering productivity and the issue isn't big enough in managements view to come in and deal with it. The issue has been brought before and ignored. It's one of the perils of being in a cost center
I have. I actually provided hard data on how daily status updates were impacting the project schedule. They didn't care. Didn't stay there long.
This is one of my big stressors right now.
A Product asks the dev manager how soon something can get done, so he urgently messages me asking for an eta. At a similar time, a product person messages me asking for the same thing.
And this is after the work is planned, pointed, and ready to work.
Worst of all, at the same time my product team is asking an eta, they're working with the marketing team to change the story!
A Product asks the dev manager how soon something can get done, so he urgently messages me asking for an eta. At a similar time, a product person messages me asking for the same thing.
And this is after the work is planned, pointed, and ready to work.
Worst of all, at the same time my product team is asking an eta, they're working with the marketing team to change the story!
The best companies I’ve worked for establish a bit of a circadian rhythm around periods of collaboration and periods heads-down time. You need time for cross-pollination and free flow of conversation and ideas, but you also need contiguous time to execute and converge those ideas.
It’s best if the people you work along side all establish this same rhythm so you don’t have some people interrupting others who are in a heads-down period, or on the other token, people missing important meetings because they’re catching up on their work. It’s even better if these periods correspond with your sprint/development schedule as well.
We’ve started enforcing this at my current company by having a calendar bot that automatically deletes meetings on certain days if engineers are on the invite list. It was painful at first but everyone eventually got on the same rhythm and now I can actually get the time to complete my work.
It’s best if the people you work along side all establish this same rhythm so you don’t have some people interrupting others who are in a heads-down period, or on the other token, people missing important meetings because they’re catching up on their work. It’s even better if these periods correspond with your sprint/development schedule as well.
We’ve started enforcing this at my current company by having a calendar bot that automatically deletes meetings on certain days if engineers are on the invite list. It was painful at first but everyone eventually got on the same rhythm and now I can actually get the time to complete my work.
A loooong time ago I worked in an open office space with the following rules:
- no headphones: you can talk to me
- headphone covers one ear: you can talk to me if it is important
- headphone covers both ears: only talk to me when the building is burning
It's not perfect by any means but it worked quite well.
- no headphones: you can talk to me
- headphone covers one ear: you can talk to me if it is important
- headphone covers both ears: only talk to me when the building is burning
It's not perfect by any means but it worked quite well.
> This is all part of the job though. People don't have all the answers and the questions are often poorly defined.
Yeah, agreed. I've started watching the balance between meetings and interruptions, and I've noticed that too many interruptions is often an indicator of too few meetings and/or poor planning, while too many meetings is often an indicator of not enough one-on-one communication in the office.
I'm fantasizing about something to schedule micro-meetings. Not a heavy hammer like days of quiet time, just something lightweight that only protects my flow-time a little bit, not a lot, by design. I want to and expect to have to talk to people, I'd just get a small amount of control over when, instead of an interruption right in the middle of my thought.
Yeah, agreed. I've started watching the balance between meetings and interruptions, and I've noticed that too many interruptions is often an indicator of too few meetings and/or poor planning, while too many meetings is often an indicator of not enough one-on-one communication in the office.
I'm fantasizing about something to schedule micro-meetings. Not a heavy hammer like days of quiet time, just something lightweight that only protects my flow-time a little bit, not a lot, by design. I want to and expect to have to talk to people, I'd just get a small amount of control over when, instead of an interruption right in the middle of my thought.
Perhaps a program that can detect when a user is in a state of flow and allow others to inquire if it is a good time to contact that person. A flow guardian.
OMG, that's a great name for the app. FlowGuardian!
Yeah, I just want to be able to fence off 10-20 minutes of flow at a time, and let a couple of questions queue up so I can answer them both at the same time.
The worst days are when I'm getting single interruptions every 5-10 minutes.
Yeah, I just want to be able to fence off 10-20 minutes of flow at a time, and let a couple of questions queue up so I can answer them both at the same time.
The worst days are when I'm getting single interruptions every 5-10 minutes.
Well-run meetings really depends on your company's culture and management support.
I find that a lot of bad meetings are driven by procrastination: The person holding the meeting is doing it as a way to get out of work. Other times, the person holding a bad meeting has an inflated ego and thinks a whole bunch of people need to pay very close attention to something that doesn't really matter.
If your organization doesn't have these problems, then great!
I find that a lot of bad meetings are driven by procrastination: The person holding the meeting is doing it as a way to get out of work. Other times, the person holding a bad meeting has an inflated ego and thinks a whole bunch of people need to pay very close attention to something that doesn't really matter.
If your organization doesn't have these problems, then great!
Another meeting problem is not delegating or assigning decisions. So you have a meeting where everybody shares their opinion, but in the end, nobody knows which opinion was solidified on and who is implementing it.
There’s only one day per week when I get absolutely nothing done: the day I have to leave home and spend half an hour commuting to work. The sense of dislocation caused by this journey is palpable. I lose context and my thoughts become scattered. I feel overwhelmed and can’t help but watch my worries come to the fore.
By contrast, working from the comfort of my home is pure bliss. I have my standing desk and large monitor. I have natural sunlight filtering in through the window. I see some trees and hear the sounds of my quiet residential street. The rhythmic cadence of my mechanical keyboard soothes me and quietes my nerves. I’m focused and ready to take on a challenge of any size or complexity.
Meetings while WFH are not a major distraction. The other participants are cleanly separated from my world. I have a high-quality headset and microphone, which takes away the stress of being misunderstood. I can easily show my screen, or say nothing at all while tuning out a meeting that isn’t helping me get my job done.
I for one am waiting with bated breath for the world to catch up with the idea that some types of work are best done from home. Offices are the true black holes into which human productivity disappears.
By contrast, working from the comfort of my home is pure bliss. I have my standing desk and large monitor. I have natural sunlight filtering in through the window. I see some trees and hear the sounds of my quiet residential street. The rhythmic cadence of my mechanical keyboard soothes me and quietes my nerves. I’m focused and ready to take on a challenge of any size or complexity.
Meetings while WFH are not a major distraction. The other participants are cleanly separated from my world. I have a high-quality headset and microphone, which takes away the stress of being misunderstood. I can easily show my screen, or say nothing at all while tuning out a meeting that isn’t helping me get my job done.
I for one am waiting with bated breath for the world to catch up with the idea that some types of work are best done from home. Offices are the true black holes into which human productivity disappears.
I'm someone that struggles to work from home, and who really likes having the dislocation. It helps me get into work mode, and back out again, it helps me separate my life and my work. I like being in place with everyone working, and much prefer being physically present at a meeting. So basically your opposite.
I think the key take away is that there should be options, what works for one doesn't for others.
I think the key take away is that there should be options, what works for one doesn't for others.
>I think the key take away is that there should be options, what works for one doesn't for others.
Pretty much the same for technical interviewing as well IMO. We'd probably like it a bit more if we at least got to choose the format.
Pretty much the same for technical interviewing as well IMO. We'd probably like it a bit more if we at least got to choose the format.
Candidates aren't supposed to like interviews. That's like saying you're supposed to like final exams at school. They should be fair, but you have no rights beyond that.
Maybe that's true for junior engineers. I'm at a point in my career where I have no doubt that I'm both highly capable and able to start delivering value quickly. When I'm going into an interview, I'm evaluating the interviewers and the company culture.
If you want to talk about linked lists and Chicago piano tuners and things, fine, I actually remember data structures and algorithms quite well even though I took those classes 15 years ago. If that's the majority of the interview though, well... it's probably not a good cultural fit. I want to make sure that the people I'm working with are human beings I can tolerate being around 40+ hours/week, and that I can trust them to make reasonable decisions.
If you want to talk about linked lists and Chicago piano tuners and things, fine, I actually remember data structures and algorithms quite well even though I took those classes 15 years ago. If that's the majority of the interview though, well... it's probably not a good cultural fit. I want to make sure that the people I'm working with are human beings I can tolerate being around 40+ hours/week, and that I can trust them to make reasonable decisions.
If you're really at that point in your career, you should find both that tech screens are easy and also that there are fewer of them.
Fair enough, I suppose, depending. Admittedly, it's been a long time since I've done one of those, but that's more to do with the fact that most of the work I've done for a while has been consulting/contracting/call-it-what-you-will, where the presumption has been that I'm coming in specifically to solve specific problems.
Right. You actually stop getting "unfair" interviews once everyone can tell you'd just pass them anyway.
Interviews, like exams, are painful when there's a big mismatch between what they should cover and what they actually cover.
If you want me to do the same sort of work as my last job, I'm naturally prepared - I've been doing it for years! But then if you interview me about unrelated garbage with no warning, I'm going to think less of your process and of your management skills.
I like good interviews for the same reason I liked most of my exams: it was a chance to show off what I've learned in a compressed format.
If you want me to do the same sort of work as my last job, I'm naturally prepared - I've been doing it for years! But then if you interview me about unrelated garbage with no warning, I'm going to think less of your process and of your management skills.
I like good interviews for the same reason I liked most of my exams: it was a chance to show off what I've learned in a compressed format.
You could also say that people don't have a right to like their job. Yet companies that want to hire and retain top talent try to make the workplace as enjoyable as possible. Can you explain why that is in a way that doesn't also justify tweaking the interview process to make candidates happier?
You're not seeing the candidates who pass "bad" interviews, who aren't complaining, and who like their jobs because the bar is high.
Of course I'm seeing those candidates. They're my coworkers. Many of them are sad that really strong people they've worked with in previous jobs. Others are sad because they have coworkers who are incompetent jerks with good interview skills.
You're assuming that the height of the bar is tied to how good people are at their jobs. You're also assuming that having a high bar has to mean that the interviews must be a bad experience for the candidates. Neither of those are true.
You're assuming that the height of the bar is tied to how good people are at their jobs. You're also assuming that having a high bar has to mean that the interviews must be a bad experience for the candidates. Neither of those are true.
I prefer work from home, but I agree with you, there should be options. As long as the option chosen has no effect at all on career advancement.
For what it's worth I find largely the opposite. Getting out of the house, the physical break of traveling from point A to point B, entering the "Working Place" with its "Work Computer" and "Work Desk" etc. all gets me focused on work. Home is too full of distractions, everything from chores that should be done, to personal projects on my computer, to that interesting magazine article I've been meaning to read lying on my desk.
The corollary to this is that it makes leaving Work at the end of day a lot easier. Once I leave the physical building where Work is done I am no longer working.
Having Home separated, both physically and mentally, from Work makes both more easy to focus on.
The corollary to this is that it makes leaving Work at the end of day a lot easier. Once I leave the physical building where Work is done I am no longer working.
Having Home separated, both physically and mentally, from Work makes both more easy to focus on.
Just to provide a differing opinion, my daily office is the place that I feel most productive. When I'm home, I'm never in work mode because I never (99.9%) work from home.
I like being around lots of people and having face-to-face conversations to work through problems.
I like being around lots of people and having face-to-face conversations to work through problems.
I agree with this 100%. I work mostly from home, and at home is the primary place where I am productive.
We meet once a week. That day in the week no work is done. Meetings are somewhat productive, and they are "required", but they don't get work done.
We meet once a week. That day in the week no work is done. Meetings are somewhat productive, and they are "required", but they don't get work done.
As nice as WFH is, I’m cautious about advocating it. We should be careful what we wish for. I’d be worried about management logic deciding that if my job can truly be done from home, it can be done from India.
And honestly, why shouldn't it? I work with an organization that has people all over the world – including India – and aside from time zone awkwardness it works pretty well. Advocating against remote work as a means to achieve job security seems incredibly backwards to me.
If your job truly can be done from India, management will have figured that out already or are already close to it. Protectionism doesn't help you, it only delays the inevitable, if you really are worried about your job getting outsourced to India it's time to upskill and do something more valuable to your local team.
Also, India is not that cheap anymore (roughly 1/3 for an engineer), and it's only getting more expensive.
Also, India is not that cheap anymore (roughly 1/3 for an engineer), and it's only getting more expensive.
Anyone thinking of outsourcing product engineering should try it. American engineers aren't in any danger.
If the only value you provide as a developer over a low-cost outsourcing agency is your physical presence in a location, then outsourcing your job is probably the right move.
Daylight hours and first-vs-second language communication differences aren't going anywhere anytime soon. These things don't affect all types of work equally, which is something useful to think about when deciding what to focus on.
Switching jobs in a couple of weeks and I'll be 100% remote - what headset/microphone do you use?
I have a HyperX Cloud II - http://a.co/1Uh0q9o - plugged into my USB hub. I like the USB audio thingamajig because it has a hardware kill switch for the mic, which I use all the time instead of on-screen mute controls. The mic and headphones are both optimized for all-day wear & talk by gamers, which works really well for my use case: working remotely.
Well I'm all set then - that's the headset I have (and love) :)
I just got a Jabra Evolve 75 headset for work a few months ago, and I'm super happy with it. It's got reasonably good ANC, and while it covers the ears, it does not envelop them like most other ANC headsets, so no more sweaty ears for me.
Noice cancellation headset with decent leather muffs will also avoid the sweat problem, I’ve found. These are usually the > $250 models, however.
I use regular Audio Technica headphones with a Mod Mic that I plug/unplug when needed.
I highly highly recommend everyone read Deep Work by Cal Newport - http://calnewport.com/books/deep-work/
The key concept Cal talks about that's relevant for this discussion is "attention residue". When you switch from low-stimuli, high-value work that requires deep focus to high-stimuli, shallower work (like meetings), it can take up to 30 minutes to really switch back to focus mode again.
Relevant excerpt on attention residue - https://hackernoon.com/excerpted-from-deep-work-by-cal-newpo...
The key concept Cal talks about that's relevant for this discussion is "attention residue". When you switch from low-stimuli, high-value work that requires deep focus to high-stimuli, shallower work (like meetings), it can take up to 30 minutes to really switch back to focus mode again.
Relevant excerpt on attention residue - https://hackernoon.com/excerpted-from-deep-work-by-cal-newpo...
During my career, other individual engineers interrupting me while I’m working has had a far greater impact on my time than scheduled meetings. What I’ve been dreaming of is an app for interrupting someone that delays requests and batches them up. No walking up to someone at any time and saying “just a quick question”, plan and expect to wait a few minutes.
In a sprint review recently I brought up the issue of, "Hi Phil." This is where someone IMs you with just "Hi Phil" and then you have to sit there and look at the "X is typing", "X is not typing" for 5 minutes.
I don't mind people asking a question, but just put it all on one line, "Hi Phil. This is the question..." That way I can sometimes just fire back a quick answer and it's not as distracting.
It makes sense too - you wouldn't walk up to someone, tap them on the shoulder and then make them wait before asking a question.
I don't mind people asking a question, but just put it all on one line, "Hi Phil. This is the question..." That way I can sometimes just fire back a quick answer and it's not as distracting.
It makes sense too - you wouldn't walk up to someone, tap them on the shoulder and then make them wait before asking a question.
I still don't understand why people use Slack for work for non-emergencies. For talking about bullshit (cool places to eat near the office) or for emergencies (@zach @sarah prod is down!) it's good, but for product planning it's terrible. Hard to keep up with, hard to reference later, encourages temporary / lazy fixes like quick questions over maintained wikis.
I keep my Slack status set to "nohello.com"[0], and ignore any messages sent to me which do not abide by nohello. It's worked pretty well so far.
[0]http://www.nohello.com/
[0]http://www.nohello.com/
I'm with you on this one, but I've recently decided that "Hi Phil" boils down to some fundamental personality split rather than a misunderstanding; I don't think either side will soon change. I believe "Hi Phil" people are really just trying to be polite and minimize interruptions (or at least their magnitude), waiting for permission to really bother you, so to speak.
Whether that's true or not, I respond if I'm ready, or I ignore it and go on with my work if I'm in the middle of something, just like I would with a full question. The only difference is I'm not thinking about the question with my spare cycles in the mean time.
If someone is trying to inform me of something urgent with "Hi Drew" I think it's reasonable to say that's their own fault.
Whether that's true or not, I respond if I'm ready, or I ignore it and go on with my work if I'm in the middle of something, just like I would with a full question. The only difference is I'm not thinking about the question with my spare cycles in the mean time.
If someone is trying to inform me of something urgent with "Hi Drew" I think it's reasonable to say that's their own fault.
No, the real reason for the "Hi Phil" and then a pause is much worse. You might sometime in the future have to contact Phil about some detail on the plan to fire "Joe". By sending "Hi Phil" and a pause you give Phil enough time to respond "I'm busy" before you give away to Joe that he is going to be out the door in a couple days after legal finishes the paperwork. Because "Hi Phil" and then a 5 minute pause is standard when this situation happens Joe doesn't think anything of it and so Phil can secretly transfer that least important bit of knowledge without giving anything away.
A "hello" comment without a question also makes me anxious, BUT I must acknowledge that from their perspective they might be doing exactly what I want, asking if it's okay to talk now, and signaling that they're willing to wait. If a question isn't asked, then you've been given permission to ignore it until ready, right?
And while the greeting without a question causes anxiety -- (you said hello... what do you need??) -- I have to say I'd rather get a lonely "hello" than a "Hey I have this insanely urgent thing, you need to help me RIGHT NOW." And I'd way rather get a lonely "hello" in Slack than have someone walk up to my desk and "hello".
And while the greeting without a question causes anxiety -- (you said hello... what do you need??) -- I have to say I'd rather get a lonely "hello" than a "Hey I have this insanely urgent thing, you need to help me RIGHT NOW." And I'd way rather get a lonely "hello" in Slack than have someone walk up to my desk and "hello".
My pet peeve is when someone does the "Hi, I have a question/problem" message without actually sending the question. It's hard to get that out of your head after seeing it. And they always seem to send the question and immediately go to lunch or a long meeting.
I explained to some people that it doesn't work well with my anxiety to see "Hey I think I found a bug in X" and then just get no further details for two hours. One person has actually listened and writes me up an email or whole long message now. Everyone else responded by saying it seemed too rude and inconsiderate to not ask about your day first so they continue to do that... You can still start your message with "How was your weekend?" but just type the rest of the message too without waiting for a response...
I explained to some people that it doesn't work well with my anxiety to see "Hey I think I found a bug in X" and then just get no further details for two hours. One person has actually listened and writes me up an email or whole long message now. Everyone else responded by saying it seemed too rude and inconsiderate to not ask about your day first so they continue to do that... You can still start your message with "How was your weekend?" but just type the rest of the message too without waiting for a response...
Yes yes yes. People are trying to be polite by not starting a conversation with a demand, but it has the opposite effect.
I just use Slack. I disabled notifications and around every block of productivity (20-90 minutes) I check my mail, slack, and random websites.
Just took a simple search "queue messages on slack" to find one - https://sv-qbot.herokuapp.com/
The description looks close to what you were expecting.
The description looks close to what you were expecting.
You might be interested in Hey[0]. I haven't used it yet, keep meaning to.
[0]: https://news.ycombinator.com/item?id=15795468
[0]: https://news.ycombinator.com/item?id=15795468
It sounds like you want to hold office hours. You don't need an app for that, you just need to respond to requests by telling people when your office hours are.
I actually tried office hours. I hung a sign on my chair during non office hours. It totally didn't work. People would shake my chair or wave at me even when I had headphones on and the go-away sign, and say "just a quick question", as if that made the interruption during non office hours okay. Some people thought I was being a jerk too.
This isn't something people can or should have to do on their own. For it to work, it needs to be a company wide expectation on a company wide schedule that immediate interruptions are off limits during certain times.
I also generally agree with "you don't need an app for that" for pretty much everything... except that this app would need to integrate and work around online calendars. And I want it to queue people so I can answer them in order. And I don't necessarily want to have a specific time for interruptions, I really want people to try to answer their own question for 5-10 minutes before interrupting me. I'm happy to answer questions, but I get a lot of questions that people can easily answer on their own with 30 seconds of effort.
This isn't something people can or should have to do on their own. For it to work, it needs to be a company wide expectation on a company wide schedule that immediate interruptions are off limits during certain times.
I also generally agree with "you don't need an app for that" for pretty much everything... except that this app would need to integrate and work around online calendars. And I want it to queue people so I can answer them in order. And I don't necessarily want to have a specific time for interruptions, I really want people to try to answer their own question for 5-10 minutes before interrupting me. I'm happy to answer questions, but I get a lot of questions that people can easily answer on their own with 30 seconds of effort.
I'm guessing you work in an open plan office like I do. It's hard to have a company-wide expectation that immediate interruptions are off-limits when that's how you sell the seating arrangement as a positive.
Yeah, absolutely. That's exactly right, the open floor plan is unfortunately intended to encourage interruption (aside from the obvious advantage of just being cheap.)
The last open floor plan I worked in established that the meeting rooms were allowed to be used for engineer quiet time, and that someone in the meeting room was not to be interrupted. It was great for the first couple of months in the building, but eventually the meeting rooms were crowded with meetings and there just weren't enough for engineers to use for focus time very often. Headphones became the only means of staying sane.
When I tried office hours, I was actually in shared offices. 4-6 people to a room. It was a game company, and I was supporting artists. The artists were the worst about not respecting office hours, most of the programmers left me alone because they also wanted to be left alone to concentrate.
Ultimately I decided I was setting a bad example by trying to establish office hours for myself. The company wasn't that great at planning, and the interruptions I was getting were a symptom of not enough training and formal communication. What was needed was a little more communication, not less. (*But the right kind, of course.)
The last open floor plan I worked in established that the meeting rooms were allowed to be used for engineer quiet time, and that someone in the meeting room was not to be interrupted. It was great for the first couple of months in the building, but eventually the meeting rooms were crowded with meetings and there just weren't enough for engineers to use for focus time very often. Headphones became the only means of staying sane.
When I tried office hours, I was actually in shared offices. 4-6 people to a room. It was a game company, and I was supporting artists. The artists were the worst about not respecting office hours, most of the programmers left me alone because they also wanted to be left alone to concentrate.
Ultimately I decided I was setting a bad example by trying to establish office hours for myself. The company wasn't that great at planning, and the interruptions I was getting were a symptom of not enough training and formal communication. What was needed was a little more communication, not less. (*But the right kind, of course.)
100% agreed that this sort of thing can't really be done on individual initiative - it just makes you look like the only jerk in the building. Same with trying to keep people from holding their loud conversations next to your desk, or put phones on vibrate/mute. If the bosses don't push solutions for these things, they don't happen.
I've actually been thinking about hacking something together for this! I can't stand slack interruptions all day, would love all requests to work with me queued up for certain designated response windows that I control so I can have longer blocks of uninterrupted time.
Doesn’t email already solve this problem?
Not at all. If people actually chose email over walking over to interrupt me, there wouldn't even be a problem.
Email doesn't help me queue up or schedule micro-meetings with people. Email doesn't do anything to work around scheduled meetings. Email is a black hole from the sender's point of view, they don't get any feedback other than a reply, and they don't know when to expect a reply. People who want immediate help will send email and then walk over and interrupt after a few minutes anyway.
Email is a communication channel. I'm not looking for a communication channel, I'm looking for a scheduler & queue for micro-meetings.
Email could work, of course, if the company sets up rules & expectation. If people knew they were required to send email before interrupting someone, and if people could count on a reply within an hour for anything, then email might be adequate, but as it stands, we already have email and we still have an interruption problem, so it's clearly not solving the problem.
Email doesn't help me queue up or schedule micro-meetings with people. Email doesn't do anything to work around scheduled meetings. Email is a black hole from the sender's point of view, they don't get any feedback other than a reply, and they don't know when to expect a reply. People who want immediate help will send email and then walk over and interrupt after a few minutes anyway.
Email is a communication channel. I'm not looking for a communication channel, I'm looking for a scheduler & queue for micro-meetings.
Email could work, of course, if the company sets up rules & expectation. If people knew they were required to send email before interrupting someone, and if people could count on a reply within an hour for anything, then email might be adequate, but as it stands, we already have email and we still have an interruption problem, so it's clearly not solving the problem.
With both email and slack (and other forms of "push" messaging) you have no control over what someone sends to you when (you could of course just close them, but then you have to remember to open them).
What I'm instead thinking of is essentially a message queue that holds any messages directed at you until you want to respond to them, and then they're all pushed to you at that time. This would also allow you to naturally auto reply to everything ("this user usually checks things around noon and 5 everyday").
Who knows, it could be a bunch of human nature that needs training that no software can do. I just know that I get a lot of "got a second?"s a day and would love a place for those to sit until I decide to get to them.
What I'm instead thinking of is essentially a message queue that holds any messages directed at you until you want to respond to them, and then they're all pushed to you at that time. This would also allow you to naturally auto reply to everything ("this user usually checks things around noon and 5 everyday").
Who knows, it could be a bunch of human nature that needs training that no software can do. I just know that I get a lot of "got a second?"s a day and would love a place for those to sit until I decide to get to them.
I should've chosen my words more carefully for such a tacit response... in this case, I'd revise it to "couldn't email solve this problem?"
I see where you're coming from though w.r.t. communication vs. scheduling. I found this on a quick search, which has a free tier that I might try: https://calendly.com. Still, my worries are that:
1. it's not like email/calendaring/slack will go away, so now I have yet another tool to maintain (at least Calendly have calendar integrations)
2. like email, it could be abused, just in new ways I don't know about yet... what problems will arise that drive us towards more new tools to solve them?
I'm not sure the marginal improvement over using email/slack/calendars, plus some sort of rules/expectations, would be worth adopting another tool, but I am curious to see how it works out.
I see where you're coming from though w.r.t. communication vs. scheduling. I found this on a quick search, which has a free tier that I might try: https://calendly.com. Still, my worries are that:
1. it's not like email/calendaring/slack will go away, so now I have yet another tool to maintain (at least Calendly have calendar integrations)
2. like email, it could be abused, just in new ways I don't know about yet... what problems will arise that drive us towards more new tools to solve them?
I'm not sure the marginal improvement over using email/slack/calendars, plus some sort of rules/expectations, would be worth adopting another tool, but I am curious to see how it works out.
I totally see where you're coming from too. You're right; it's not necessarily an app that I want. Ultimately, it's expectations & behaviors that I most want to change, not add yet another app to my day.
Email is a low priority queue, and it’s gotten to the point where it’s unreliable because everyone’s inbox is overwhelmed.
Slack is (or should be) a high priority queue. It seems like something in between is needed. A place for “please deal with this soon, but don’t stop what you’re already doing” and that has far less noise than email so you know a request will be seen.
Slack is (or should be) a high priority queue. It seems like something in between is needed. A place for “please deal with this soon, but don’t stop what you’re already doing” and that has far less noise than email so you know a request will be seen.
Not when you can get funded to make an app that implements AI and ML to create a sorted message queue that increase business resiliency in agile environments. In all seriousness I'm looking forward for the announcement from a startup that boils down to "We made email again"
Slack at least tries to use platform notifications so you can use your OS' Quiet Hours / Focus Assist tools for immediate help with it.
Email?
Most people I've ever worked with treat email as an immediate conversation. If you don't respond within 20 minutes (and typically within 5) they'll send another, try me over chat, or even call and immediately go "did you see my email?"
I sometimes takes days to respond, unless something is truly urgent – which of course it almost never is. For whatever reason this pisses some people off, but they also learn that the best way to get an immediate answer out of me is to call (I work 100% remote.)
I sometimes takes days to respond, unless something is truly urgent – which of course it almost never is. For whatever reason this pisses some people off, but they also learn that the best way to get an immediate answer out of me is to call (I work 100% remote.)
I answer my emails immediately it stops the calls. I prefer this.
> "I hate email. Sometimes I won't get an answer for a few hours, or sometimes until the next day" -- Coworker
It's definitely a culture thing. I've worked with teams across the spectrum, and, personally, I definitely lean far towards async communication being the best most of the time. There's times when you can't beat a whiteboard session, but those are the exception for me.
It's definitely a culture thing. I've worked with teams across the spectrum, and, personally, I definitely lean far towards async communication being the best most of the time. There's times when you can't beat a whiteboard session, but those are the exception for me.
E-mail should be this tool but yes, it’s use is way too company culture dependent. Some places/people treat reading/answering email as optional. Some batch it up and “do Email” 1 day a week or so. I wish there were a better work communication tool with the response expectation of chat plus the asynchronousity of Email.
If someone at my company routinely doesn't answer internal emails then they should be fired.
What if they're too busy doing work?
If they're routinely dropping emails then they haven't communicated up and down that they're overloaded or they're in a shitty work environment. Either way, I've been on the other side of dropped emails and it's like sand in a motor. It's precisely why most large organizations have issues being agile.
What's routine mean? I've had people that go all Peter Potomus and start beating down the office door if you don't reply to their insane, rambling emails inside of five minutes, screeching "Did you get that THING I sent YA!"
Email is a medium that should require a little bit of thought and deliberation, and if you're doing it, you can't do much else. Incoming-email-driven development is one of the more frustrating and wasteful processes I've suffered through. Ping ping ping, bouncing all around, not concentrating.
It's also worth trying to cultivate some self-reliance in your coworkers, so they learn how to find information and solve problems on their own, without needing their hand held every step. It's sometimes overwhelmingly difficult not to send back a lmgtfy link to some questions.
Email is a medium that should require a little bit of thought and deliberation, and if you're doing it, you can't do much else. Incoming-email-driven development is one of the more frustrating and wasteful processes I've suffered through. Ping ping ping, bouncing all around, not concentrating.
It's also worth trying to cultivate some self-reliance in your coworkers, so they learn how to find information and solve problems on their own, without needing their hand held every step. It's sometimes overwhelmingly difficult not to send back a lmgtfy link to some questions.
No. Email is not a scheduler, and it has never stopped someone from interrupting me. If email solved this, there wouldn't be a problem.
I want something that forces people to try to answer their own questions for a few minutes, or at least expect to wait, before asking. When there's a small cost to asking the question, a high percentage of the time, the request will vanish on it's own. The asker will answer their own question or realize the question wasn't what they really wanted to ask.
Part of the point of what I'm suggesting is to allow people to cancel their request. With my app suggestion, I'm hoping/expecting like half the interruptions (random made-up number) to just go away. Email doesn't do that, in fact it gets worse with email, you waste time reading the question and again reading the answer, or worse, answering the question only to find out the "nevermind" email was buried further down.
I want something that forces people to try to answer their own questions for a few minutes, or at least expect to wait, before asking. When there's a small cost to asking the question, a high percentage of the time, the request will vanish on it's own. The asker will answer their own question or realize the question wasn't what they really wanted to ask.
Part of the point of what I'm suggesting is to allow people to cancel their request. With my app suggestion, I'm hoping/expecting like half the interruptions (random made-up number) to just go away. Email doesn't do that, in fact it gets worse with email, you waste time reading the question and again reading the answer, or worse, answering the question only to find out the "nevermind" email was buried further down.
No, it's 2018, we need some new app to disrupt the tried-and-true method of message delivery.
I think there is a problem with too many meetings though. I used to have morning and afternoon meetings every day. Certainly made my schedule full but also meant I got less done.
The biggest problem for corporate meetings and perhaps why there are so many of them, why they're so frequent, and why they're so long:
* Meeting initiator fails to really consider if everyone on the invite list needs to be there.
* Meeting initiator fails to consider if a meeting will have all the necessary people in attendance in order to have the meeting (and furthermore, what if a required attendee can't make it? Can you still have the meeting? If so, they probably didn't need to be there in the first place)
* Meeting initiator does not have much of an agenda or firm outcome in mind when organizing the meeting (other than some topic or 2... i.e. "Discuss new feature X")
* Meeting initiator and/or attendees don't take any notes at all and then don't distribute the notes to people who may want to be informed but simply did not need to be in attendance.
There are other issues with why there are so many meetings, too, such as the structure of the organization and/or project being worked on, whether the culture of the company hinges on having "buy-in" from many different stakeholders, or a consistent "ask for permission" kind of culture. Also, a culture where people don't interact well between groups (marketing and engineering, product management and QA, and so on) or have poor relationships between these groups. Meetings serve as a more formal proxy in order to get people informed or consensus on things between disparate groups in the organization. These are additional factors that seem to play into the need for more meetings.
* Meeting initiator fails to really consider if everyone on the invite list needs to be there.
* Meeting initiator fails to consider if a meeting will have all the necessary people in attendance in order to have the meeting (and furthermore, what if a required attendee can't make it? Can you still have the meeting? If so, they probably didn't need to be there in the first place)
* Meeting initiator does not have much of an agenda or firm outcome in mind when organizing the meeting (other than some topic or 2... i.e. "Discuss new feature X")
* Meeting initiator and/or attendees don't take any notes at all and then don't distribute the notes to people who may want to be informed but simply did not need to be in attendance.
There are other issues with why there are so many meetings, too, such as the structure of the organization and/or project being worked on, whether the culture of the company hinges on having "buy-in" from many different stakeholders, or a consistent "ask for permission" kind of culture. Also, a culture where people don't interact well between groups (marketing and engineering, product management and QA, and so on) or have poor relationships between these groups. Meetings serve as a more formal proxy in order to get people informed or consensus on things between disparate groups in the organization. These are additional factors that seem to play into the need for more meetings.
At my workplace we have a daily DMZ (De-Meetinged Zone) from 11 to 3. Since engineers tend to roll in btwn 10 and 11 and most product ppl work normal hours and leave by 6, you end up with a lot of meetings btwn 3 and 6. But at least they aren't methodically fracturing your entire day anymore.
Care is needed when scheduling. Standard parallelization stuff. If all your sub teams want to have sub team meetings (retro, planning, blah blah), try to parallelize those meetings so there's more time on the clock for cross team meetings. If you don't do this, manager schedule ppl will start violating the DMZ.
To manage Slack interruptions disable whatever your personality is distracted by. For me I turn off all notifs that aren't direct messages to me or @mentions. I hide chat rooms with no unread messages. And most importantly I don't keep Slack on top 24/7 on some second monitor. When ppl need me the client grabs my attention and I answer. The rest of the chatter can be read at my leisure. We use emojis in our engineering channels to make it easy to scan for action items like code reviews and we use threads for replying to ppl so the channel is like the top level view of a message board.
This is functioning fairly well with ~30 engineers at the org but i think we will need to more consciously manage the 3-6 window if we doubled in size again. Fred Brooks stuff, the 3 hour window is fixed but as teams grow so does the communication overhead.
Care is needed when scheduling. Standard parallelization stuff. If all your sub teams want to have sub team meetings (retro, planning, blah blah), try to parallelize those meetings so there's more time on the clock for cross team meetings. If you don't do this, manager schedule ppl will start violating the DMZ.
To manage Slack interruptions disable whatever your personality is distracted by. For me I turn off all notifs that aren't direct messages to me or @mentions. I hide chat rooms with no unread messages. And most importantly I don't keep Slack on top 24/7 on some second monitor. When ppl need me the client grabs my attention and I answer. The rest of the chatter can be read at my leisure. We use emojis in our engineering channels to make it easy to scan for action items like code reviews and we use threads for replying to ppl so the channel is like the top level view of a message board.
This is functioning fairly well with ~30 engineers at the org but i think we will need to more consciously manage the 3-6 window if we doubled in size again. Fred Brooks stuff, the 3 hour window is fixed but as teams grow so does the communication overhead.
What killed me was that people wouldn't schedule back-to-back meetings because of stragglers to the second one, cutting into it. This meant that there would be an hour meeting, then an hour gap, then another hour meeting. Never enough time to get back into "the zone" in the code.
The last company I was at set the meeting times to end 5 minutes before the end of the hour (or half hour) to prevent this issue.
It helped but wasn't completely effective since we were split over 3 floors of a building (floor 4, 20 and 21), so it could take over 5 minutes to get from room to room.
It helped but wasn't completely effective since we were split over 3 floors of a building (floor 4, 20 and 21), so it could take over 5 minutes to get from room to room.
I would rather see a stripe through my schedule, say 1pm-3pm everyday, that could be used for meetings.
I actually enjoy the break sometime and the sidebars on the way to and after the meeting are sometimes great ways to get micromeetings done.
Having the rest blocked gives me a two solid blocks of three hours to do stuff.
I actually enjoy the break sometime and the sidebars on the way to and after the meeting are sometimes great ways to get micromeetings done.
Having the rest blocked gives me a two solid blocks of three hours to do stuff.
My previous company was awful about scheduling meetings. They had a strong propensity to throw big timewasters right in the middle of the most focused part of my day, like sprint planning and all-hands meetings.
Probably part of the reason I'm gone now, but it is incredibly annoying to be in a groove and forcibly interrupted in the middle of it for an managerial ego-stroking session. (Also, you're paying me a decent chunk of change to sit there bored out of my skull).
Probably part of the reason I'm gone now, but it is incredibly annoying to be in a groove and forcibly interrupted in the middle of it for an managerial ego-stroking session. (Also, you're paying me a decent chunk of change to sit there bored out of my skull).
Alternatively, I schedule 9-2 for every day as programming time. A company-wide policy though would be great, and having entire days blocked on or off for programming sounds like it would work much better than my method across timezones. However, having a couple of hours at the end of each day is super useful to keep collaboration with non engineers humming too.
The vast majority of individual contributor developers do not have the freedom to simply block off two thirds of their time at work from meetings. Company cultures differ widely - I've worked places where each of the following were true:
- Meeting organizers actively used the scheduling assistant to determine the best time and room for a meeting
- Meeting organizers picked whatever time and/or location was most convenient for them and whoever made it made it
- Meeting organizers picked whatever time and/or location was most convenient then threw a fit if you declined due to another commitment
If you're a junior dev and your lead schedules a meeting for 11am you'd be hard pressed to tell them to pound sand because that's your programming time. Seniors have more leeway but I'm sure seniors at Facebook or Microsoft still probably aren't declining meetings with their boss because it's programming time.
- Meeting organizers actively used the scheduling assistant to determine the best time and room for a meeting
- Meeting organizers picked whatever time and/or location was most convenient for them and whoever made it made it
- Meeting organizers picked whatever time and/or location was most convenient then threw a fit if you declined due to another commitment
If you're a junior dev and your lead schedules a meeting for 11am you'd be hard pressed to tell them to pound sand because that's your programming time. Seniors have more leeway but I'm sure seniors at Facebook or Microsoft still probably aren't declining meetings with their boss because it's programming time.
I would submit that a) given the hot job market, ICs have more freedom to improve work practices than they think, and b) changes like this get much easier if they are done collectively.
As we see in this case, it started with one team. A junior dev can't unilaterally change the schedule, but they can certainly point out the problem, see if others are feeling the pain of too many meetings, and propose an experiment to improve productivity. And then if a whole teams says, "Manager, we are eager to be more productive, so we are trying X," it's going to be pretty hard for a manager to say, "No, productivity isn't important here."
As we see in this case, it started with one team. A junior dev can't unilaterally change the schedule, but they can certainly point out the problem, see if others are feeling the pain of too many meetings, and propose an experiment to improve productivity. And then if a whole teams says, "Manager, we are eager to be more productive, so we are trying X," it's going to be pretty hard for a manager to say, "No, productivity isn't important here."
But it would also be easy for the manager to say "No, meetings are the tax you pay for being part of the organization."
I am moving teams at the end of the month and I look forward to suggesting this to my new manager, perhaps just a day or two to start and review the VCS after a few weeks to see how much more gets done on those day(s). I just think it would be very easy for a manager, especially a non-technical one, to disregard this entirely.
I am moving teams at the end of the month and I look forward to suggesting this to my new manager, perhaps just a day or two to start and review the VCS after a few weeks to see how much more gets done on those day(s). I just think it would be very easy for a manager, especially a non-technical one, to disregard this entirely.
My company has a designated no-meeting-day for engineers and it's been good for the reasons in the article - I'd love to see it expand. It's also nice to have a designated day that everyone gets errands done. Need an oil change and they're only open during business hours? Great - everyone gets it done at the same time when they're not trying to contact each other - no need to coordinate.
The other thing has been as a last-resort day for meetings that really need to happen soon, but half the people you need to get in the room are just in meetings all the time except that one special day, so you make a special one-time exception when you really need to. I suspect that this is just a band-aid though - those people can't be as productive as they think they are if they can't control their schedule more.
The other thing has been as a last-resort day for meetings that really need to happen soon, but half the people you need to get in the room are just in meetings all the time except that one special day, so you make a special one-time exception when you really need to. I suspect that this is just a band-aid though - those people can't be as productive as they think they are if they can't control their schedule more.
This is great if the whole company agrees on the no meeting day. If every team has a different day, and I have to hold a cross-team meeting, then at least one person will have to violate their no-meeting day.
I try my best to respect people’s preferences but if by some miracle I’ve found a time slot that is actually free for the other 6 participants but happens on your “no meeting day” I’m going to regrettably have to schedule it then.
I try my best to respect people’s preferences but if by some miracle I’ve found a time slot that is actually free for the other 6 participants but happens on your “no meeting day” I’m going to regrettably have to schedule it then.
Please please please let that mean "no meetings and no slack". Otherwise what's the point?
Try this neat trick: disable push notifications for email, Slack, HipChat and any other communications except emergency channels such as PagerDuty. This will do wonders for your productivity. I’ve faced some blowback from people who expected me to respond immediately in real time, but I’ve assuaged their concerns by explaining my focus model and the need to eliminate distractions. In my experience, my correspondents actually enjoy receiving a thoughtful reply composed in my own time rather than a snap reaction fired off just to get the sender off my lawn.
Another neat trick I've picked up on from other people use is to use DND mode on Slack when you're focusing. That way if it's actually critical to get a hold of you in real time (but not so critical that it warrants a page) there's an option to do that.
People are surprisingly respectful of it, and unlike just going dark it signals to people that you're available if need be but focused on something.
People are surprisingly respectful of it, and unlike just going dark it signals to people that you're available if need be but focused on something.
I just got the new touchbar MacBook — making DND a primary shortcut was an easy way of making this completely frictionless.
I agree with this sentiment. In smaller startups, I feel like the bigger distraction is Slack. I've found that closing Slack for a few hours a day results in me having a more productive day.
Note: notifications are disabled on Slack, but it still causes distractions.
Note: notifications are disabled on Slack, but it still causes distractions.
From the article: "Slack lets us talk and make the same decisions we would have made in meetings anyways.". So there's still IM etc.. Easier to turn off, though, no?
I came here to ask about this exact same thing...
How do they address the onslaught of Slack interruptions?
How do they address the onslaught of Slack interruptions?
We do this, with Mondays and Fridays being commit/celebrate days respectively (work still gets done on those days but the meetings that set/review the sprint goals are held on them), and the three middle days of the week being "focus" days. It's worked well for us so far.
I’ve worked on some pretty complex stuff in my time and I can only think of maybe one time where it was necessary to have a ‘meeting’ (which was more like an impromptu ‘let’s get 3 people to whiteboard this instead of 2’). I find the concept baffling and assume it’s for the benefit of people who don’t do anything to feel good about themselves. (Especially the “daily stand up” concept.) Anything complicated enough to require input from multiple parties is usually better discussed asynchronously via email. But I also don’t find interruptions to be particularly distracting so maybe I just don’t get it.
If you are in control of your own calendar, don't wait for your org to do something like this: just block off your own productive time and decline all meetings during it.
I have about 20 hours worth of meetings per week. I've been arranging my meetings into as few days a week as possible, and it helps a lot, but eventually there always ends up being overflow into other days. I've also gotten complaints that I'm not flexible. Lastly, I've found these days to be utterly exhausting where by the end of the day I'm non-functional. It is much better than constant interruptions, though.
We broke the time up into mornings and afternoons. Most mornings and afternoons were "no meetings" time. If there was a meeting scheduled in a morning or afternoon, then that became the prioritized time to schedule any other meetings that came up. Worked great.
Most people aren't willing to skip meetings, or walk out of meetings when they realize the meeting is unproductive. Both are productive behaviors.
Most people aren't willing to skip meetings, or walk out of meetings when they realize the meeting is unproductive. Both are productive behaviors.
When trying to minimize meetings across my team, I have found Google Calendar to be the enemy. Anyone in the company (or even externally) can just put an event on your calendar, the default is 1 hour, and expect people to attend the meeting because “it’s on the calendar”. There is no way to enforce some kind of policy (no-meeting hours/days, max time, max attendees). Any tips for restricting GC?
make your own events on the calendar during the time you don’t want to be in meetings
Yep, schedule "work blocks" in the calendar - it's usually a good way to combat frivolous meetings, and if something's important, then they'll probably schedule it over anything in any case.
The “Decline” button is there for a reason. You can configure Google Calendar to delete declined events from your calendar. Your response will show up on the other participants’ calendars as well, so they’ll know that you’re not coming and will either proceed without you or reschedule.
You can also propose an alternate time, which can be seen as less standoffish.
You can also propose an alternate time, which can be seen as less standoffish.
> You can configure Google Calendar to delete declined events from your calendar.
Ah that would be very helpful.
The thing is, as engineering manager and gatekeeper to my team, I would like to make those RSVP decisions for people on my team. We can solve this with organizational/communication policies, but was hoping to enforce within GC as well.
Ah that would be very helpful.
The thing is, as engineering manager and gatekeeper to my team, I would like to make those RSVP decisions for people on my team. We can solve this with organizational/communication policies, but was hoping to enforce within GC as well.
I’ve been in your shoes. Hats off to you for trying to do right by your team. I’ve had success with coaching my employees to refuse any meeting invite that would not directly help them do a better job. We’ve come up with verbiage to help redirect meetings to me so that no hard feelings could crystallize on the other side. This works except in a small minority of cases: some individual contributors enjoy their meetings. It’s not my place to stop them.
> This works except in a small minority of cases: some individual contributors enjoy their meetings.
Also in a small minority of cases breaking up a developer flow to provide on the ground context in a meeting is better for the organisation than keeping the developer in-flow for another hour.
Rarely, I'll concede, but it's worth remembering that few developers are paid to "code", but to create value for the organisation. The vast majority of the time that's done by coding, but sometimes (in those rare moments) that value is derived from a meeting.
Also in a small minority of cases breaking up a developer flow to provide on the ground context in a meeting is better for the organisation than keeping the developer in-flow for another hour.
Rarely, I'll concede, but it's worth remembering that few developers are paid to "code", but to create value for the organisation. The vast majority of the time that's done by coding, but sometimes (in those rare moments) that value is derived from a meeting.
Maybe the company needs a positive consent policy, only persons who respond "going" will be assumed to be present?
The idea of mental multi-tasking as a productivity killer makes me wonder if people with ADHD would function better in a team lead role (eg: they have to go to All The Meetings) rather than a role where locking down and focusing for 12 hours at a time is needed. I have enough ADHD that I appreciate the interruption of flow that meetings allow me... or am I just weird?
I may try this myself. I work on my own. But, I find stuff like appointments, phone calls, errands, occasional tutoring, etc really slows down work. Even the gym, which I do MWF.
So, Tuesday-Thursday might me an ideal set of days to schedule nothing. It still leaves two days to schedule external things. I tried a one day system before but it was too rigid.
So, Tuesday-Thursday might me an ideal set of days to schedule nothing. It still leaves two days to schedule external things. I tried a one day system before but it was too rigid.
We work quite closely with the team in Europe so usually all meetings are in the morning and afternoons are always free. Its a great way to work. The suggested having days on and days off I've learned leaves the problem that its often impossible to code 10 hrs straight. Having blocks each day is my preference.
Besides the actual topic of the post, there is one gem that, IMHO, every manager should realize:
> As engineering managers, it’s our job to provide the space and support needed to help our engineers deliver great software.
The best managers I encountered were not telling the team what to do, but enabling them to do what needs to be done.
> As engineering managers, it’s our job to provide the space and support needed to help our engineers deliver great software.
The best managers I encountered were not telling the team what to do, but enabling them to do what needs to be done.
Lately it feels like all I do are meetings. I never feel like I'm doing any work.
The only meetings engineers should have are 1) regular status/planning meetings and other agile related meetings. It's a good idea to block these in a single time block. 2) one on ones with managers. These are short meetings and can be planned well in advance or be very adhoc. 3) whiteboard meetings for problem solving. Everything else tends to be a waste of time. 4) very infrequent all hands type meetings.
Since leaving the corporate world, I've been doing startups and freelance work. I tend to not use a calendar for meetings because they are so rare these days. Likewise, I've all but eliminated email from my life. It's just not a thing anymore to read and write lengthy emails. We use slack to replace both meetings and email.
Since leaving the corporate world, I've been doing startups and freelance work. I tend to not use a calendar for meetings because they are so rare these days. Likewise, I've all but eliminated email from my life. It's just not a thing anymore to read and write lengthy emails. We use slack to replace both meetings and email.
I love the sentiment, but I feel like this imposes significant costs on non-engineers, and ultimately on the whole team.
Product managers, UX, and others need significant input from the engineering team to make good decisions (i.e. not design un-buildable things). And the idea that they can go for 3 business days a time without that input seems... unrealistic and/or counterproductive.
But of course meetings should be limited as much as possible... include just the relevant engineer(s)... and trying to cluster meetings instead of spreading them throughout the whole day...
Product managers, UX, and others need significant input from the engineering team to make good decisions (i.e. not design un-buildable things). And the idea that they can go for 3 business days a time without that input seems... unrealistic and/or counterproductive.
But of course meetings should be limited as much as possible... include just the relevant engineer(s)... and trying to cluster meetings instead of spreading them throughout the whole day...
Meetings are usually a poor way to gather information. I really wish people would send me a well thought out email with clear questions before they fall back on bringing everything to a grinding halt so they can talk in person.
This might make sense if your engineering team finishes the roadmap and then reduces tech debt to a level they are comfortable with... but since I'm sure that's not the case, you should be happy with 2/5ths of their time.
Sounds wonderful! I look forward to those days where I am not interrupted by a useless meeting or conference call. Unfortunately, they are rare.
How do you run stand-ups with no meetings whatsoever? Is the hope that you get asynchronous communication through slack?
When I was in a team that did stand-ups, I convinced them to do it in Slack vs. via phone (in-person was not possible because the team was distributed). We set up a daily channel reminder in Slackbot that contains the traditional standup questions.
One team I worked on distinguished "meetings" from "conversations". The former being formal, scheduled things with agendas, and the latter being people on the team talking about things as needed, with people showing up if they wanted. We had very few meetings.
Technically the stand-up would have been a meeting. But since it was our choice, we would have probably considered it a conversation, as it was not some uncontrollable schedule bomb, but our way of getting the day started.
Technically the stand-up would have been a meeting. But since it was our choice, we would have probably considered it a conversation, as it was not some uncontrollable schedule bomb, but our way of getting the day started.
how do you manage stand-ups with this schedule? Just try to check-in/co-ordinate informally via Slack?
Do you find standups actually useful? Or are you doing them because agile companies do standups?
I've never found any utility in standups at all, and the days we missed the standups were no different to the days we have the standups.
I've never found any utility in standups at all, and the days we missed the standups were no different to the days we have the standups.
i used to find standups to be useless hurdles put on the track by my manager. now i find them more useful, or less useless, because after 10 minutes have passed i just start coding again.
it's a bit absurd if you ask me. Have meeting when you need to. avoid useless meetings.
That sounds nice, but doesn't work in practice. When it only takes one person to call a meeting, the larger your company gets, the more likely it is that somebody will think a meeting is useful. This is made worse by the way larger companies tend to rely more on power structures, so it's considered bad for a low-status person to say no to a high-status person.
There are certain people in companies who if they aren't in meetings all the time, would probably have very little to actually do.
I think for those people meetings are saving their job.
I think for those people meetings are saving their job.
Why just engineers.
What about the designers?
Does anyone really love meetings?
What about the designers?
Does anyone really love meetings?
people who can't contribute anything individually
So I have to wait three days to discuss something of substance with an engineer? Sure, I didn't need to get anything done this week.
Reminded me Paul Graham's Maker's Schedule: http://paulgraham.com/makersschedule.html
Did you read the article? That is referenced, and quoted, several times, starting in paragraph 3.
Of course it does. It's quoted and linked right at the beginning of the article :)