Maker's schedule, Manager's schedule (2009)
paulgraham.com
paulgraham.com
Please - just don't hire for this position to begin with.
It's amazing to work with a good team lead like that since you can focus 90% of your working time on getting top priority things done.
What I've seen from the opposite approach is that ICs have a lot of pressure to estimate, plan, document, communicate etc because the managers are too detached from the day to day work. Almost no actual work is getting done because of all the interruptions and endless technical bikeshedding because nobody has either the authority or understanding to call the shots. The ICs compensate for this by working overtime for free.
What you're describing is a good manager, period. You can't slot an MBA with no engineering experience into a TL position, to serve as some kind of bureaucrat. When the team's stuck in the weeds, a good leader rolls up their sleeves and helps. It just goes to show what a sorry state the industry is in, that we no longer think of that as intrinsically a leadership skill.
* quick dog walk/sunlight
* meetings
* dog walk/sunlight/lunch/exercise
* focus work
* dog walk
* personal development/curiosity/light work
* dinner/etc
I actually really enjoy breaking up the day with walks and exercise. I usually try to have at least one day with no meetings for two focus blocks but I found there is definitely diminishing returns there. I think ideally I'd do the meetings in the afternoon but the timezones involved prevent that. I'm not the highest-volume IC but I'm reasonably good at identifying high-value targets since I have a lot more context so in the one focus block a day I can do some damage. If it's a bigger project I might just try to start it/find the shape of it and then shop it around to get it on the appropriate teams roadmaps.
It's pretty crazy to me that the people making most of the resourcing decisions in companies were maybe once technical but haven't actually pushed a line of code in years so that muscle has atrophied and this leads to a complete lack of nuance in decision making. So I definitely think you need at least few 'blended' roles who keep their technical chops a bit honed but still participate in the 'command'/resourcing discussions (but of course I'm biased).
I give it a year and that time will fill up with meetings too =)
Many startups have inexperienced first time leaders at the top who are still running on pure adrenaline. They work unsustainably (not realizing that yet) and create such expectations for everyone else.
You’re constantly pushing beyond 100% in peace time. Now imagine war time. It gets bad - toxic even.
This is an interesting model, because it means when someone disagrees with their tech lead they are explicitly not disagreeing with their manager but with a peer.
The managers also can't assign work (explicitly or implicitly) because they're not even on the same team. This stopped a bunch of non-planned work, such as when a manager said something like "it would be nice if you built x" or asked questions that required a lot of research, as it's too easy for an IC to take that as a directive to actually do it. Now that is more like "good idea, you should ask my tech lead or PM to create and prioritize a ticket so I can do it."
The real position that needs to go away are EM1, EM2, Director, Senior Director, Assistant VP, VP, SVP etc.
These positions are mere reporting chains. They have so much free time that they end up playing politics and performance review games. Nothing they do actually benefits the product.
The ideal structure imo is Tech lead reporting directly to a director. It is the directors job to make strategic choices, and tech lead's job to split the work into composable parts that lead to delivery.
Multiple tech leads can work together, under the direction of the director.
All pay, performance, bonus nonsense should be offloaded to an administrative assistant person whose job title is called administrative assistant.
Make the company more technical, not more managerial.
For me, the context switching issue can often be mitigated by dumping my brain into written form. Much like testing, it often feels like things are being slowed down, but usually pays itself back.
With this approach, I usually find that an hour of uninterrupted time is sufficient.
Of course, this doesn’t somehow mean that meetings are an effective use of time. In my experience, most meeting time is wasted because people are not writing down and organizing what is in their head.
Writing things down really helped give me a better perspective on the process I use to organise work as well.
Makes getting back into the flow of a project pretty quick
The only solution I can think of about the meeting problem is to have them all in the same day. A day with even just one meeting is ruined, however you organize it. Let's have them all the same day.
My usual response is to not even remember what was discussed minutes after it's over.
But I also think most of the meetings I take part in are useless.
This was in 2015, and they’d been doing it for some time prior.
>They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started.
Seems ... made up?
There are all sorts of things you can do in an hour as a programmer: update a test, fix an automation script, fix and/or test a bug.
Not all programming starts with grandiose algorithm design or an architectural green field. Some does, so there's a small nugget of truth, but this is far too great a generalisation.
I do agree with the difference in schedule though. Having worked on both IC and mgmt tracks, it was easy to see a whole day fragment in to nothing when needing to get on the critical path.
Frequent disruptions to this are deeply frustrating and almost every dev I’ve worked with has made similar remarks. Poor meeting scheduling is a guaranteed way of ensuring your devs have little to no motivation to do anything.
In a previous job we called Wednesday “Meeting Wednesday” because total meeting time was at least 4 hours sometimes with small gaps between where nothing would get done.
Sure you might be able to do small tasks that truly take less than an hour but in reality that’s rarely the case.
Presupposing that all programming is in the pursuit of grand designs (i.e. it take half a day to a day to make meaningful progress on any task) is the only thing that would justify it. But the reality is, it isn't like that except for a subset of specific engineers in specific roles and industries.
Inversely, chopping up developers' days might be one way to keep them small, bug-fixing, value-tweaking, code-pasting peons.
Free time to work between meetings is rarely filled efficiently. An one hour gap is either filled by something that's finshed in 45 minutes with the remaining 15 minutes difficult to fill, or filled by something that takes 1.5hrs and therefore requires a context switch.
With meetings its different. They last one hour because they last one hour, not because the content takes one hour to discuss.
But like 1 hour slots for work the same is true for fixed 2-week sprints.
And for containers on shelves, which cannot be placed where the frames are.
You can add to existing understanding or analysis quickly if you have an overview. To create a new overview is a bigger undertaking.
Anecdotally, I do like to have discrete, 4 hour blocks of time, and this is something that seems pretty common (though not universal) among the experienced devs I’ve worked with.
The point is not about whether a task ends up being less than an hour. That happens all the time, as you say.
The point is that, when beginning the task, it is entirely unknowable whether it's definitely going to fit within an hour or not. Any of the 3 examples you gave — updating a test, fixing some automation, or fixing a bug — are things that can easily blossom into all-day (or all-week) tasks.
And so, with 60 minutes and 3 tasks that might be doable within the time, it becomes that much more difficult to justify investing the time to get into flow exactly because of that unknown ROI. Plus, you need N minutes to get into flow and M minutes on the other side to prep for the meeting, so you only have 60 - N - M minutes to invest anyway.
There's a guarantee of an interruption to flow within the hour, but there's no guarantee the probably-small-but-possibly-enormous task will be done by the time that interruption arrives.
Taking the maker's schedule into consideration in small companies seems relatively easy - especially when the CEO's coding alongside you. But I'd be interested to know if there are any medium- to large-sized companies who actively think about this and deal with this problem successfully as opposed to just always giving in to the manager's schedule.
The dynamic hasn’t changed because managers do not actually want productivity from their developers. They want legibility and alignment. They want to see what their programmers are doing and they want to know they aren’t doing anything extraneous because they want to see that their schedule is on track. Productivity is a developer problem. If there is a problem with getting things done, it’s a problem with individual developers and not the environment.
The real solution to this problem is to give developers control over their work environment. If developers are in a position to reject meetings and avoid interruptions they are more productive. We’ve seen this happen with WFH and hybrid work environments. This has increased productivity and worker satisfaction. This has also taken away management legibility and alignment and is driving companies to require workers to return to the office despite the benefits.
So I guess my point is that many seem to focus discussion on remote work, when really we should be aiming higher. Working remote is the shit, doing laundry during the day is nice, but we all know we can’t go yellow on Teams or lose our green bubble on Slack lest there be hell to pay.
If you ask most high-ups in your software company whether they would rather a 100% guaranteed release date of Sept. 1, 2023 or a 75% confidence sometime between July and October, if they are honest with themselves, they will admit they would rather have the 100% date. So much other stuff needs to happen on fixed dates. Marketing campaigns need to ramp up, sales teams need to get started, maybe your project is part of a bigger product which has a known release date, maybe your project gets flashed onto hardware that goes on a boat on some fixed date.
It would be so much easier for software companies if making software was like making a bolt or a screw: Raw material go in -> machines do their machining -> product come out a known time later, at a known rate, with a known yield.
Specifically on the cost of meetings to developers.
This article is a pure product of this period when software developers thought themselves as extremely special and above such petty issues as having to attend meetings. It’s entitlement masquerading as wisdom. The truth is everyone has to balance their time between obligations and slots they can allocate to do longer work. Writers have to meet their editor. Artists have to plan for the logistic of their exhibitions. That’s part of life.
You can work for a bit do something else and get back to what you were doing. If you can’t that’s an issue with you, not the nature of your work.
A) “All meetings are a waste of time.”
B) “There are productivity tradeoffs between a managers schedule and makers schedule.”
Editing some text or repositioning a button or something trivial is 30-min and does not require thought, but most everything is not this. Most everything involves large chunks of time and interrupting this chunk is certainly a disaster.
- both a maker and manager
At the end of the day, most of us expect to get paid for the code we write. At some level, there is a customer who is ultimately paying for this code. You need to communicate with them via some means or you won't be able to do your job effectively. Either you talk to your team on some recurring/ad-hoc basis, or you get to talk to the end customers directly.
Which one would HN prefer? Filtered internal comms channels where you get to whine and moan about basically everything, or the direct fire of the actual customer where everything is on their terms always? What would ruin your "flow" more? A boring 30 minute call where you were informed the customer is "not happy" or a 2 hour, unfiltered rant session from the live customer?
I don't really have this problem, but my co-workers often put several-hour meetings on their calendar with the meeting name and participants hidden. Seems to work to prevent others from inviting them to meetings during that time.
That seems quite top heavy. I wonder if your need to be proactive is less driven by the structure of your office and more by the number of bosses you have.