
Makers, Don't Let Yourself Be Forced into the 'Manager Schedule' - huntermeyer
https://blog.nuclino.com/makers-don-t-let-yourself-be-forced-into-the-manager-schedule
======
heyflyguy
I had this exact situation come up with an engineer that I can only call
brilliant, with the most conservative of overtones. He was more than that.
Being a maker myself I gladly encouraged him to work when he wanted, sometimes
that meant he'd work 48 hours straight and sleep for two days and show up
Friday. His 3 days of work (as his peers would describe it), easily was double
the quality and output of his closest colleague. I loved having him on my
team.

Eventually, other people started asking to work 3 days a week, suggesting that
they too would pull all-nighters in an effort to have 2 mid-week days off. I
let a few experiments happen but sadly in most cases the result was less than
50% of what they had been previously able to accomplish.

This led to a new merit based working system when we placed emphasis on
sprints and achieving. This too ended up failing because the interconnected
dependandcies of sprints were always bottlenecked by the slowest operator.

The final result was the eventual departure of my most prized teammate, and
mostly due to peer pressure. I often think about how I could have better
allowed his brilliance while not alienating the rest of his team, but in the
end I failed.

~~~
PragmaticPulp
I had a similar brilliant engineer with odd working hours at one point. I also
had the same problem with other engineers requesting the same odd hours, with
equally negative results.

In my case, I eventually learned that the odd hours weren't the key to his
perceived success. Instead, he used the odd hours to force us to give him only
work that could be accomplished alone. We were lulled into letting him make
key architecture decisions in isolation, because no one else was awake or
online at the same time to discuss them.

Eventually he became the architect by virtue of operating in isolation, where
we couldn't discuss his decisions. Everyone else was forced to work around his
code. If he refactored the codebase in the middle of the night to make his job
easier, the other team members were all forced to work around his refactor and
waste time updating their PRs to match his work.

Worse yet, having someone like that on the team drives away other great
employees. Eventually everyone else will get sick of accommodating the
architects isolated schedule. If they have other opportunities, they'll leave.

> I often think about how I could have better allowed his brilliance while not
> alienating the rest of his team, but in the end I failed.

It's not on you. Brilliance and individual productivity aren't everything in a
team setting. If your project must scale past a single person, you need
everyone operating on the same page. It's painful in the short term to lose
the quirky rockstars, but it makes for a healthier team in the long run.

~~~
protonimitate
> Brilliance and individual productivity aren't everything in a team setting.
> If your project must scale past a single person, you need everyone operating
> on the same page. It's painful in the short term to lose the quirky
> rockstars, but it makes for a healthier team in the long run.

I think this is a self-inflicting ailment in the tech world. Many who are ICs
fancies themselves one of these mythical "rockstars" who can code the business
saving solution in 24 hour benders. Management/hiring/culture in general put
too much emphasis on the brilliance of a single person on the team. But as you
said, there's a time and place for the brilliant IC, and that's usually the
very very early stages of a business.

I've seen this sort of situation play out at my current job. We had a
"rockstar" who was with us from the beginning. He was able to ship solutions
extremely fast, was a fantastic eng, but loved to do things on his own
schedule. He was the backbone of the eng side of the business... until he
decided to take an offer somewhere else. He pulled off a crazy last 48 hour
bender to wrap things up he was working on, but in his haste left behind a
half-finished total rework of the back end which nobody other than him had a
vision for.

We spent the next 6 months trying to understand and finish where he was going
with this rework. The manager who enabled this from the beginning also left,
so we were left with a bigger mess than when we started.

Sure, this particular eng got a metric ton of features shipped in our early
days, but in the end ended up costing almost as much to clean up his mess as
the value we got from him in the first place.

There's a way to make these situations work, but blindly enabling the whims of
the rockstar is not it.

~~~
1MoreThing
As a manager, a big part of our job is to mitigate risk and single points of
failure. If enabling someone to work like this increases risk and creates SPOF
in our teams, we're screwing up letting them do it.

~~~
lixtra
> As a manager, a big part of our job is to mitigate risk and single points of
> failure.

No, your job as a manager is to understand the trade-offs of taking such risks
and make a decision that fits your situation.

I.e. your competitor may capture your market with a single engaged risky
engineer before you can produce anything usable with your best practice low
risk team. Once they capture the market, they can stabilize later and hire
your team, because you went out of business.

~~~
ameixaseca
That is one of the very important points a lot of people are missing here, and
a key argument of the article: a fast rendering engine was a requirement for
quake to be as popular as it was and it was a product of a brilliant engineer
doing something innovative.

More often then not, innovation comes from a reduced number of people doing
things differently, and it's very hard to assemble a team of engineers which
is willing or even capable of doing this sort of work.

This also comes back to the "decision shielding" from working different hours:
it's very common for managers or people averse to risks to try to stick to
solutions they know, even if they are suboptimal or do not fit the problem
very nicely.

Anyone capable of doing more will soon realize they are spending most of their
time solving mismatches between what solution was used/implemented and the
problem they were trying to solve. If they don't find an alternative or a way
around these limitations, they will leave.

~~~
fuzzfactor
With real rock stars, or movie stars, the manager of course reports to the
star and serves at their disposal.

Manager may have some challenging performances lined up and the creative
operator has to really toe the line, but the purpose of the team is to support
that to the best of their ability.

Anything less, and the desired expression of talent might be dampened. If this
is too severe expect the star to move away toward a more functional
arrangement.

------
twblalock
The ability to work during normal business hours, dealing with interruptions
and collaborating with your colleagues, is a skill that every engineer should
develop.

This skill doesn't come naturally to some people, but it can be developed and
it will make you more productive.

In particular, develop the ability to enforce encapsulation on your mental
model of the program you are working on, so you don't need to keep the entire
thing in your head all the time (this will probably make your code better
too). This makes it easier to get back into the flow after being interrupted.

The most productive engineers I know work during normal business hours, get
interrupted constantly because they work on important projects with a lot of
stakeholders, and get a lot of work done anyway. That's what 99% of engineers
should aspire to. There are very few rockstars like Carmack who are so good
that the benefits of their crazy work styles outweigh the drawbacks.

~~~
emptysongglass
Science says you're wrong and not only wrong but this mistaken belief some of
these people hold that they can multitask or be interrupted without
significant loss of productivity is actually an admission that they are the
worst of multitaskers. [1]

The mind is single-core. There's no black lotus you can huff or secret
technique to master to make it more than one core. And the inertia returning
to its task is significant.

[1] [https://www.npr.org/sections/health-
shots/2013/01/24/1701601...](https://www.npr.org/sections/health-
shots/2013/01/24/170160105/if-you-think-youre-good-at-multitasking-you-
probably-arent?t=1573504082179)

~~~
McWobbleston
I think you've missed their point. Those engineers are aware of the cost of
context switching, and because they plan accordingly they're able to get more
done than those who don't

~~~
mikeg8
Awareness and planning cannot compensate for the fact that lost productivity
is lost productivity.

~~~
throwawayjava
I tend to agree with you, but I'm compelled by the argument that organizing
your productive time in a way that minimizes the impact of context switches
_will make your programs much better anyways_.

There might be a good reason why code developed under extreme focus also tends
to be inscrutable to others.

~~~
splittingTimes
> There might be a good reason why code developed under extreme focus also
> tends to be inscrutable to others.

Wow. I have never thought about it this way. That's quite a profound insight.
Thanks.

~~~
techopoly
On the other hand, extreme focus can and should be used to make a complex
algorithm simple. It all depends on the programmer's competency to begin with.
If he/she doesn't care or know how to make code readable, it never will be
readable despite their level of concentration.

The corollary is true as well. I, as well as many others I imagine, have had
to fix and maintain dumpster fires of spaghetti code developed under the
standard distraction-filled modern business day.

Distraction doesn't beget good code; instead, a good programmer learns how to
be as productive as they can despite the dysfunction of a typical modern
business.

------
ben7799
I feel like we're only having this discussion at this point because:

\- Agile brought interruptions to a new level of pain

\- We have too many instant interruption communication points (slack)

\- Open Offices have made interrution far worse

There were books about this concept 30 years ago. It was totally recognized
that you shouldn't break up an engineer's time into tiny chunks with 1000 cuts
worth of meetings.

But we threw it all out the window in the last 10-15 years with the rise of
Agile + Open Office + Instant Message/Always-On communication programs.

~~~
bonestamp2
Out of all of these things, open offices have been the worst in my opinion. At
least with slack (or whatever other messenger you use) you can ignore that
until your thought is complete or you want to make a quick note of your
thoughts before allowing the distraction. When someone taps your shoulder it's
much harder to ask them to wait, so it happens much less than it should... not
to mention the constant passive distraction of people moving around and having
other conversations.

We used to be in small offices of 2-4 people. That was perfect and I miss
those days. The office looks a lot nicer now that it's open, but it's a
disaster from a concentration standpoint. But, I think a lot of managers like
the open concept because it's easier to see people and because it does often
look nicer and often has more natural light.

~~~
mc3
I have never worked in a 2-4 office and certainly not a 1-office, but I find
about 10 in an office is manageable if they are all quiet non-phone-calling
people.

I worked a place with 400 people in open plan close proximity, where your
workspace doubles up as a corridor, and no meeting spaces, so it also doubles
up as a meeting room for any teams meetings. It was impossible to concentrate.
That drove me to some Howard Leight earplugs, beefy headphones with "the ocean
machine set to 9". The impomptu meetings now sounded like a squeek, but it was
still distracting.

I had to leave that job because of this and other negative effects of a
cattle-like approach to handling software talent.

------
tboyd47
The fact that he had to work at night in order to get any concentration time
would be a company culture fail in most situations. But, the devil's in the
details.

> David Kushner reflected on the unconventional working style of the company's
> ace coder, John Carmack.

"Ace coder" isn't quite accurate job title. He was a co-founder. People act
differently when they have legal ownership over their work.

~~~
throwaway10x
I work very late into nights on the project I created. I hate myself sometimes
for doing this because this now the company's cash cow and I get nothing more
than any other engineer. I've contemplated quitting but I see no benefit to
this, it's still one of the coolest projects I've worked on. It's not just
legal ownership that can drive people.

~~~
tboyd47
Why not just put your resume out there and see what happens?

------
throwaway713
As a maker (individual contributor), I have been having this issue a lot, but
my attempts at pushing back do not seem to be going so well. Any time I
reserve a large chunk of time on my calendar, people set up meetings on top of
it anyway, or message me asking if that block time is "real" (as though quiet
focused work isn’t a thing).

My days are filled with little dabs of 30 minutes here and there that are
barely enough to remember what I had been working on before another meeting
started, so I normally end up getting my actual work done late at night after
an early dinner, which my wife is not particularly happy about.

Any recommendations? I’ve broached the topic lightly with my manager but don’t
want to come across as whining, so I’ve generally just been trying to push
back on meetings in the friendliest way that I can.

~~~
LegitShady
>people set up meetings on top of it anyway, or message me asking if that
block time is "real"

Your problem here is you. You were booked. When someone sends you a double
booking, hit "DECLINE" and they get an email right away saying you declined
it.

Then you say "Hey I already had something in my schedule for that time, can't
make it. You have access to my calendar why would you make meetings when I'm
busy? That isn't very respectful."

If someone asks if a block of time is "real" always say yes. your problem is
that apparently you have blocks of time that aren't real. if you only have
real blocks of time in your schedule, nobody will guess which aren't or are
real.

If someone asks you in person, have the backbone and willpower to say "Hey I'm
already booked" and suggest another time.

You're the one causing your problems, but you're describing it as other people
doing it to you.

~~~
jedberg
The problem is that when you do this, and then don't go to the meeting, and
then a decision is made that you don't agree with, you are told, "well you had
a chance but you didn't come to the meeting".

The other problem is that sometimes people will literally see you working in
your cube/office during the meeting and then ask you why you declined if you
clearly weren't busy, because they don't equate coding with being busy.
Sitting at your desk == not busy in their mind.

So now you have a political problem because you're seen as uninterested/not a
team player.

~~~
nwalker85
>>Sitting at your desk == not busy in their mind

Maddeningly, these are the same people who feel like you have to be in the
office 100% of the time so they feel like you are working.

------
scandox
Sometimes the problem can be one of self-definition, or of self-definition
over time. Professionally, I have had years where I was definitely in maker
mode and years where I was in manager mode. There are times when for a few
months your head is down and you're just making stuff. Then the making slows
down and what you've made goes into maintenance or into a next planning phase
where lots of things have to happen at the same time.

The problem can be that some developers see themselves as forever in maker
mode: in other words they treat being asked to talk and discuss things as mere
interruptions.

A lot of managers I think are quite traumatized by this in a way: they can
feel like they literally have no power to make things happen. As a result they
may well over-react over the course of a career and treat anyone in maker mode
as simply another developer who won't talk to them.

~~~
dsaavy
Phew, thought I was the only one who went through these cycles. The maker >
maintenance > manager/planning cycle always feels unsettling during the
maintenance phase.

------
the-dude
[https://hn.algolia.com/?q=manager+schedule](https://hn.algolia.com/?q=manager+schedule)

[http://paulgraham.com/makersschedule.html](http://paulgraham.com/makersschedule.html)

And 7 days ago :
[https://news.ycombinator.com/item?id=21440456](https://news.ycombinator.com/item?id=21440456)
( The Manager’s Schedule Is Holding Back Remote Work )

------
war1025
The endless focus on "rockstar" productivity seems misplaced to me. This is a
profession. You're going to be doing it for a long time. No need to burn the
candle at both ends.

------
kmstout
A few things that I've found helpful:

1\. I start my day a couple hours later than typical for my organization. This
both lets me work quieter hours and shaves time off my commute.

2\. From 2 p.m. on is reserved as "Real, Actual Work" on my calendar.

3\. I check email a few times a day. Any other time, Outlook is closed. Those
who need me immediately can call my phone or visit my desk.

4\. At least once a week, usually Friday, I work either as late as I can or
until I reach a suitable milestone. The clock doesn't matter.

------
C0d3r
> At the same time, real work is not getting done. Meaningful work is usually
> done quietly and in solitude.

You can do great work by pairing or mobbing too. Being isolated is good, but
it's harder to learn new things working by yourself.

~~~
pmorici
"it's harder to learn new things working by yourself."

I strongly disagree. I rarely learn anything of consequence when working with
others. Pairing and mobbing strike me as fads.

~~~
geerlingguy
Some people thrive in that kind of environment (XP and all that), I know it
sucked the soul out of me the one time it was forced on my team at a prior
employer.

------
thrower123
It's often less the "manager schedule" that is the problem, but getting
screwed into complying totally with the "customer schedule."

The one that has been the bane of my existence for years now is the 9AM daily
call with the customer that is on Europe or Delhi time. It just destroys the
day when you start things off with that kind of thing, and get immediately
tossed into placating and containment mode. Then whatever you thought you
might be able to do for the day gets tossed out the window in order to react
to the latest fire drill before the next call. It's entirely reactive, rather
than proactive, and it is soul crushing.

It's almost lunch time now, and I haven't done anything worthwhile yet today,
other than try to bring some kind of order to this chaos and triage.

~~~
aisengard
Unfortunately, your role is "customer support engineer". Ideally there is
another team that does not directly interact with the client that is actually
able to get real work done on the product. Try to get on that team.

~~~
thrower123
You have to wear all the hats on a small team, unfortunately.

Between Thanksgiving and New Years is typically one of the better periods of
the year for getting real work done, so there is that to look forward to.

------
gowld
I find that the simplest way to avoid getting stuck on someone else's schedule
is to get a ~month ahead of your expected productivity (even if that means
sandbagging estimates, or working extra, or accepting a bad performance rating
because you are holding back on reporting your accomplishments), and then
whenever you are asked for status update for management/customer, report what
you were working on last week/month, not what you are working on right now.
This means you are never playing "catch up" externally to yourself. It's like
having a month of living expenses saved in your bank account it's a month of
political capital saved up at your job.

------
draklor40
Carmack was able to choose his timings because it was HIS company. People
worked for him, not vice versa. To be the master of your time, you have to
work for yourself, not under someone else. When reality and idealism clashes,
reality wins.

~~~
kukabynd
Couldn’t say it better. This is something most people who work for others
don’t understand.

------
wizzard
> The reason why many managers fail to see and address this problem is that
> they are used to looking at communication and assume it's a good thing.
> Because they see activity. People are attending meetings, talking to each
> other, the online presence indicators are bright green. Clearly, a lot of
> work is happening!

Yes, this. And a similar problem occurs when manager-types try to come up with
metrics to measure programmer productivity. Their yardsticks for what
constitutes meaningful work, as a manager, cannot simply be translated over to
makers.

~~~
kraigie
>manager-types try to come up with metrics to measure programmer productivity.

Plenty can. The CFO types look at profit per commit/schedule whatever.

A lot of middle managment types look at activity per commit.

The real issue here is that mangement by productivity data. Means most
management is deadweight that can be replaced by a spreedsheet with the
ability to send form emails to those falling behind on the metrics.

Anywhere else would be downsized, but management has enough power go protect
it's own existence at the expense of the company.

------
PragmaticPulp
The core message is true: Constant interruptions are bad, dedicated periods of
focus are good, managers should help foster sustained focus for their
employees. I think we can all agree on that.

However, this isn't an unbiased article: This company wants to sell you a SaaS
product that they think will reduce interruptions. They have an incentive to
make you think that the manager's schedule is as terrible as possible, because
they want you to sign up for their SaaS tool. In my experience, each
additional SaaS tool piled on to developers, no matter how well-intentioned,
just introduces more distractions and overhead. Reading toward the end
suggests some possibly helpful tools, but I'm not seeing anything that can't
be accomplished with some common sense and existing tools.

This blog post has unhealthy amounts of exaggeration and hyperbole. Consider
the "Actual Schedule" chart in this article that only shows blocks of "Ruined
Morning" and "Ruined Afternoon". Or the claim that a single standup meeting
can blow an entire afternoon because it interrupts the afternoon flow. The
study they linked doesn't even support such excessive problems with
disruption.

These exaggerated narratives are seductive for two reasons: First, it's true
that interruptions come at a cost to focus on other tasks. Second, it gives us
an easy out to blame everyone else for our lack of productivity or focus. Did
I waste my afternoon on Twitter and HN instead of getting my work done? Well,
I read an article that says it's my manager's fault for that 30 minute
scheduled meeting that I've known about for a week. It's always tempting to
blame someone else, especially when there's a shred of truth to it. I'll admit
that I fell into this trap for a while when I was younger.

Having grown up on "Maker's schedule vs. manager's schedule" I was a die-hard
believer that managers had it easy, while engineers got the short end of the
stick due to all of those pesky distractions. When I switched to management, I
was shocked to discover that I still needed periods of sustained focus and
that I still had problems dealing with interruptions. The maker vs. manager
distinction I had learned about didn't really exist, but in the manager role I
had no choice but to work around it. Once I stopped blaming everyone else for
my poor ability to recover focus or get into flow states, I became much better
at managing my own time.

I firmly believe that articles like this are counter-productive, because they
send a message that poor time management and excessive time wasting are not
your fault, and therefore not your responsibility. That mindset closes the
door for any possibility of improvement, which is the opposite of what you
want. Yes, it would be great in an ideal world if we could work for a week
straight without interruptions, but that's not reality. Instead, focus on
skills to better manage your own time and plan around interruptions.

Practice responding to people with "I'm in the middle of something right now,
can we talk about this after our scheduled meeting in the afternoon?" to
coalesce your meetings together. Or statements like "I'm happy to help, but
I'm really busy right now. Can you write this up in an e-mail, cc my manager,
and we'll look at it in the morning?" If your manager is to blame, broach the
subject in a professional manner and politely ask if your manager can help
batch your interruptions into a single daily conversation. Put it on the
calendar if you must, but the important thing is to take charge of your time
management.

Finally, put deliberate effort into getting back into a flow state after
interruptions. If your first reaction after returning to your desk is to open
up HN or Twitter, then you're part of the problem. I've found that putting my
headphones on and spending 10-20 seconds mentally retracing my steps before
the interruption is very helpful.

~~~
tracer4201
Context switching is expensive. I agree with the strategies you shared for
better managing time, but you seem to be interpreting the article as literally
manager vs maker, as if there’s a strong adversary between the two, when in
reality, an engineer who’s expected to attend all the meetings and also be
able to turn around designs and code is just not going to be as effective
because of the high cost of context switching. The authors point stands.

Somehow you managed to see the worst in this, making the article about
yourself, and you even accused the author of purposely misleading to sell his
or her product. If you’re a manager, I would encourage you to be more open
minded, for the sake of your employees if nothing else.

~~~
war1025
I think the parent post was spot-on.

> an engineer who’s expected to attend all the meetings and also be able to
> turn around designs and code is just not going to be as effective

Then maybe they are having too much asked of them. Or perhaps the meetings are
actually more important than the coding tasks and that is why they get
priority.

People need to learn how to delegate and how to let go. There is only so much
time in a day. Either you delegate production tasks to someone else, or you
let go of control and let people make decisions in meetings without your
input. Both are valid responses to time pressure, and usually you need a mix
of the two.

~~~
kraigie
>Or perhaps the meetings are actually more important than the coding tasks and
that is why they get priority.

If that is the case. Then the programmers KPI and perfomance review should be
based on how many of these meetings they attended.

Hell if meetings really are more important and add to productivty. How about
paying meeting attendance bonuses?

No one will put there money where there mouth is because they know it's a
waste of time to have a meeting that could be an email.

They need to look busy to justify their own salary

------
peferron
My impostor syndrome briefly reappears every time I read articles like this :)
I don't feel any state of "flow" or "zone" or whatever, and certainly wouldn't
consider my entire afternoon ruined because of a single meeting in the middle
as illustrated in the article. If there's a hard problem to solve, sure, I'll
work on it until 4 AM because I have a hard time letting go of unfinished
things, but that's mostly throwing hours at the problem and I don't think I'm
massively more productive than during the day at the office.

~~~
throwawayjava
Intense focus can be a symptom of ADD/ADHD [1]. I've always wondered if
software developers who experience flow/zone (myself included) have varying
levels of mild ADD that presents as intense focus.

[1] [https://www.additudemag.com/understanding-adhd-
hyperfocus/](https://www.additudemag.com/understanding-adhd-hyperfocus/)

------
TomMckenny
If you genuinely are an X times programmer, unless you find the right
environment, it is irrelevant. You will find under-utilization is common and
so burnout comes quickly. As you can see in the comments, many places are
unable to find ways to maximize your productivity. And once underutilized, you
are of less value and so less valued. And even though these places will want
you, they are a catastrophically bad match.

Since the risk of burnout from frustration is real, if you value your career,
you will need to leave such places quickly until you find one that can utilize
you maximally.

------
lxe
Conversely, get better at handling interruptions. In almost every non-junior
role (not just "manager") you will be required to deal with many things
throughout the day, coding being just one of them.

~~~
rch
> almost every non-junior role

To me, this sounds far from being universally true. Some Sr. roles allow for
hard-split meeting days vs. productive days, and moving to six week self
managed "sprints" with regular updates to a draft publication instead of
shuffling vaguely defined tickets around a board.

~~~
kraigie
>Some Sr. roles allow for hard-split meeting days vs. productive days

Such as?

------
alchemism
It’s practically from another era at this point, but on this topic I cannot
recommend enough _Time Management for Systems Administrators_ [1].

Ops Engineers have the Firefighter-Maker-Manager dilemma to contend with. The
techniques to balance reactive work with planned work adapts well to SWEs in
open offices with too many meetings.

[1]
[http://shop.oreilly.com/product/9780596007836.do](http://shop.oreilly.com/product/9780596007836.do)

------
galaxyLogic
To be a SW rock star you need to master 3 languages:

1\. The programming language used and its (de facto) standard libraries

2\. The language of the important design- and tooling patterns that are useful
in the said programming environment

3\. The language of the Problem Domain.

If you can master all three, then you are a rock star your productivity will
be much higher than those of your colleagues who have not achieved the mastery
of these.

Now what is the language of the problem domain? Often it is just the methods
and functions already present in the application. Here whoever made the
original design has a clear advantage over others who started working on the
same application later.

When starting from scratch it is the language of the business, say accounting
terms, and their meaning if you are building an accounting system of some
kind.

The code is just something written in these 3 languages, if you can speak in
those languages you can write the code down, and can read it and understand it
and thus modify it further.

To master all 3 of these languages can take a lot of effort over time. But so
it is with true rock stars. Think Jimmy Page, he had a long career on stage
and in studio before he joined Led Zeppelin.

------
mathattack
Who are these managers with nice even 1 hour blocks? My time gets chiseled
down to 30 and sometimes 15 minute blocks, with rampant double scheduling.

------
cwyers
> At the same time, real work is not getting done. Meaningful work is usually
> done quietly and in solitude.

I don't really like this definition of meaningful work. Yes, there are some
tasks that require focus and inventive mental work. But those aren't the only
tasks a "maker" faces. And they aren't always the most important ones.

------
jpincheira
Totally. These days what I do is I allocate time for features/product and just
go hard on it for Standups [1]. I do say 1-2 weeks building product as if it
were a hackathon. When I am done, I go back to marketing & sales, in the
manager's schedule.

So in short, I do things on consecutive days:

* to code, I do maker's schedule.

* to sell/talk to users, I do manager's schedule.

I'm feeling like writing on the topic as well, as it can be valuable for other
solo founders too. I struggled a lot in the beginning when building Standups.

[1] [https://standups.io](https://standups.io)

~~~
npo9
Why do you do both? Why not stick with the one you enjoy the most?

~~~
jpincheira
Because to do creative (product: code/design) work I have to really get
uninterrupted streaks of work.

But to do sales, talking to users, I have to do it on the manager's schedule,
with the typical slots within a day calendar schedule.

~~~
npo9
No. You misunderstand. Why do you want to do both creative work and sales?

------
gdubs
I'm curious what the meeting schedule of Bell Labs was like. I get the sense
that the researchers had plenty of time to invent, take naps in their office,
and at the same time bring a lot of stuff to market.

------
cjfd
This is kind of true but the article is pushing it a bit far. In the schema
there is an afternoon with block of two hours. One would hope that a maker
could do something in a two hour block...

------
meristem
I agree with the post's view of maker time. I disagree with its ideas around
manager's ideal schedule. My experiences as a manager were that the
disruptions of hourly 'something new' were unhelpful for strategy development
or even moving the tactical horizon to something past 'next week'. This
resulted in my 'actual' work being done before anyone else arrived or after
everyone else left. I have met very few managers who did not have similar
concerns.

------
systematical
I was digging this blog until...

"The most straightforward way to address this is to build a team knowledge
base. Not only does that minimize the number of repetitive questions bounced
around the office, it allows new team members to basically onboard
themselves."

# Insert nuclino advert #

Right....That's a culture thing, more than it is a software solution. You can
only use a software solution to aid the culture, not the other way around.

In my experience, This culture needs to come from the top-down.

------
orev
Good idea in theory. Almost impossible in practice.

------
mark_l_watson
I have always time shifted my working hours, at SAIC, Angel Studios, Google,
and Capital One I would arrive very early to get some quality thinking and
coding time - and then leave early. Some people at work probably thought I was
goofing off, but they would roll in at 9am and not know I got to work hours
before they did.

------
graphememes
As a manager it's very hard to get everyone else on board with this

~~~
kraigie
>As a manager it's very hard to get everyone else on board with this

If management was easy then everyone would do it.

How about this for a start? You taking total control of your direct report's
calendar. They have read only so can see what meetings you have scheduled they
should attend. You book the meetings.

Anyone who wants a meeting has to disturb the manager (so there will be fewer
requests) and pushback will have more force.

It's not whiny engineer saying they can't attend the meeting. It's the manager
saying they are too busy.

You could also send just 1 report to a meeting instead of the whole team.
Since you control the calendar you can choose who goes.

------
GCA10
Paul Graham is so very, very right when he highlights the limitations of
managers' view that "one hour" is an important increment of time.

For me, the most important interval is a decade. Get your big goals right, and
that huge swath of time will let you do something hugely transformative in
your work, your sidelights or your personal relationships. But to get there,
you need the stubbornness to work through the hard stuff for a long time
without immediate rewards.

You also need the freedom to reinvent your approach a couple times, without
feeling embarrassed or doomed.

Being a maker calls for a totally different clock.

------
ThomPete
The makers response should always by default be. “Do you want i know or when
its done” then after that a discussion about delivery schedules can be had.

------
teekert
Agreed wholeheartedly, in fact I try have meeting days and work days, the
workdays I am usually working from home.

------
bayesian_horse
Erm, working at night has some serious health disadvantages. even if you get
enough sleep during the day. One of the worst things you can do is switch
those schedules regularly.

Some people may be able to do this, especially for a few months or years. Many
however, will break down sooner or later!

~~~
tluyben2
I have heard this before (long haul stewardesses and breast cancer I think)
but was that researched enough to say it like you say? Quite a lot of people
who do this for decades without issues... I can see how it can be bad for
people, but is the cause of that too little sleep, some reason of anxiety
being unable to cope with 'the day', doing drugs, some stress factors that
make it easier to work when the rest sleep etc; if one exchanges night with
day fully, has that been proved to be objectively bad?

~~~
bayesian_horse
There may be people who can shift their night cycle, maybe even because of
genetics or circumstance, but medical science says that circadian rhythms are
hard to change and changing sleep cycles too fast leads to issues.

And this may also be a case of how many problems you have. Night shifts might
not be a problem on its own, but throw in a little depression, or getting
overweight, or whatever, and it's going to suck big time.

------
ilaksh
My suggestion is that you get rid of the managers and have senior engineers
manage themselves.

------
dfilppi
That's why remote workers are more productive, provided they can get isolated
at home.

------
martin_henk
Actually someone understands my trouble

------
meed
So much truth...

------
edisonjoao
interesting

