
Ask HN: IT Directors and VP's – how do you manage your time and projects? - stackdestroyer
Over the course of my career I&#x27;ve been fortunate to have able to develop as an engineer and sysadmin, and did very well at tackling the projects and tasks that came with those roles.  With success in those roles, I found pleasure in managing people and technology, and worked to get promoted to manager, and later director and VP roles in my organizations.   The challenge I have faced the further up in the org I go is in changing my work style, tactics and approaches to be more effective.  I often find myself overwhelmed with tasks, while projects also need attention.  The question for HN is:  How do senior level technology managers, directors and VP&#x27;s manage their time, projects and tasks to be effective at those levels?
======
sokoloff
You need to stop doing your old job and start doing your new job. That sounds
obvious, but I see a lot of people get promoted and keep doing their old job,
the one that they were so good at it and came so naturally. Even if the new
person in your old job is only 25% as good as you are at, let/make them do it.

Related, if you can see a better way to do it, strongly consider _keeping your
mouth shut_ if that way is only 5% better. If you improve the project by a few
percent and sap your report's motivation and confidence by 50%, you're
probably not making things better for your company. Save your insights for
times where you think your way is 50+% better.

In short, if you are overwhelmed, make sure you're doing your executive job.
If you're not, consider still spending more time on reading and thinking
rather than defaulting to pitching in on a project deliverable if it isn't
written in English prose (feel free to work on a project high level summary,
objectives, and key results document).

~~~
yters
This is exactly the problem I see with my division's supervisor. He was a
developer, and is now a program manager, but he wants to directly influence
every single project instead of delegating. What is an effective way to
encourage him to do his new job?

This is impacting the team b/c he takes away lower level decision making
responsibility, while not spending the time he needs to spend planning out and
setting top level vision.

~~~
jedberg
Well you have a few options. You'll have to gauge your own situation to see
what you can get away with.

1) Ask him for his deliverables to you frequently. If he's a program manager,
presumably part of his job is to fill you in on context and the goings on
outside of your group. Ask him for those regularly. Ask him to present the
planning and top level vision.

2) Be direct and tell him what you just wrote -- that you expect him to
delegate and trust and not dictate now that he's been promoted.

~~~
yters
I've done #2 a number of times, and #1 is a great idea, too. If I keep him
focused on #1, it'll be harder for him to hop the line.

------
edw519
I'll steal a quote from Pittsburgh Penguins (American professional hockey)
head coach Mike Sullivan: "Play the game the right way".

Just do the right thing. Always. If you're not sure what that is, figure it
out however you can, and do it. This time. Every time. Always.

Once you start doing that, all the other BS melts away.

A few personal thoughts of what "the right way" means in IT:

    
    
      - Treat everyone else like you want to be treated. No "talking down".
      - Got Business Requirements? Are they any good? That may be your problem.
      - Same thing for Technical Specifications.
      - Same thing for Test Plans.
      - Is everyone working on their most important thing? Why not?
      - Will it affect the annual report? Yes? It's an issue. No? It's a detail.
      - Keep the process that's needed. It helps.
      - Ditch the process that's not needed. It hurts.
      - Go with your gut. That's what got you here.
      - If it needs changed, change it. If you don't, it'll change itself some other way.
      - Correlation != Causation.
      - Know the Critical Path.
      - Keep your finger on the pulse of everything you can.
      - Programmers produce. Everyone else must support them. (Never forget this!)
      - If it's not written down, it's not.
      - Relax and have fun. Can't? Find another career.

~~~
howenterprisey
List for mobile:

> Treat everyone else like you want to be treated. No "talking down".

> Got Business Requirements? Are they any good? That may be your problem.

> Same thing for Technical Specifications.

> Same thing for Test Plans.

> Is everyone working on their most important thing? Why not?

> Will it affect the annual report? Yes? It's an issue. No? It's a detail.

> Keep the process that's needed. It helps.

> Ditch the process that's not needed. It hurts.

> Go with your gut. That's what got you here.

> If it needs changed, change it. If you don't, it'll change itself some other
> way. > Correlation != Causation.

> Know the Critical Path.

> Keep your finger on the pulse of everything you can.

> Programmers produce. Everyone else must support them. (Never forget this!)

> If it's not written down, it's not.

> Relax and have fun. Can't? Find another career.

------
sz4kerto
This is not about time management at all. Many new execs mess this up -- it's
not that you need to get more organized (or mostly not); you need to build a
system that doesn't require you to intervene all the time.

What this requires is

\- people you can trust

\- you actually trusting them

\- being able to identify relatively self-contained tasks you can delegate

\- being able to accept that you'll get less competent in things you're
delegating

Ofc. there's much more to this, there are plenty of books, courses, schools
about leadership and management, but I think the core issue is that you should
concentrate of make yourself not required.

~~~
emptybits
I think this is an excellent way to look at the situation.

From a psychological POV (e.g. ego & identity), this aspect was particularly
significant to me as I moved from developer to manager to CTO and then CIO:

> \- being able to accept that you'll get less competent in things you're
> delegating

------
brycethornton
I highly recommend reading "The Manager's Path" by Camille Fournier. It's a
great overview of the different things to consider while working your way up
the ladder (specifically in engineering management).

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

~~~
pete23
I’ve upvoted this, but want to underline that this book is truly excellent.

------
ska
I’ve watched many people in these roles, and had them at various times.

One of my takeaways was this. Everybody has a system, but it’s not that
important what the system is. What is telling is what happens in a
“challenging situation”. Is your system what you rely on to get you through
it, or is it what you abandon when the chips are down - only to pick up again
when things cool down? In my experience, the people in the former category
perform much better, with fewer surprises. If that isn’t you, ask why.

I’ve seen people do this well using everything from a fully manual system
(engineering notebook/journal) to total commitment to something like omnifocus
to a sort of personal wiki to one based on emacs .org mode. I think the key is
to find (and customize) a system that is comfortable for you and you trust -
and make it very easy to use. Simpler is probably better.

Another thing to note, the first time you have an EA you’ll have to adjust
your patterns to make both of your time more effective.

One last thing - how effective do you feel you are at delegating? The bigger
the group under you, the more you have to let go of details to keep your focus
where it matters. Communication trumps almost everything else.

------
matchagaucho
More meetings seems like a bad cliché, but it's really the most impactful
activity.

Meetings with customers (internal and external). They need to trust that you:
a) understand their problems b) will commit to a service level agreement c)
will convey the needs to your team

Meetings with team. 1:1 with each member at least once every 2 weeks.

Make sure to understand their personal situation. SO's name, kids, anything
going on that might risk churn.

Make sure they are aligned with customers needs. Empower them to meet with
customers directly and form their own solutions.

Follow-up on their concerns and "surprise" them with actions that show you
were really listening.

Pipeline Always be recruiting, refining job descriptions, interviewing, and
hiring.

Technical Strategy It's the thing technologists love most. But at Sr
Management level you're empowering teams to choose frameworks/languages,
building alignment, and helping them make decisions to move forward.

Note that I don't mention _politics_ in any of the above. If you gain the
trust of customers and employees in 1:1 meetings above, this should
preemptively mitigate politics.

------
sciurus
Check out Will Larson's post on time management.

[https://lethain.com/time-management/](https://lethain.com/time-management/)

He has a lot of great posts on leadership and management; here's a collection
of some of them- [https://lethain.com/rails-for-engineering-
leadership/](https://lethain.com/rails-for-engineering-leadership/)

~~~
stackdestroyer
Huge value here - great to see another tech->mgr telling their story about how
they got better.

------
Spooky23
You can’t directly manage more than a half dozen people, up or down. If you’re
in a place with heavy management, that’s something you need to work with.

Your key objective is to get people in place to operate independently. You
need empower your people so they are managing the projects.

If you’re doing a lot of heroic tasks, especially in a bigger org, you’re
approaching the ceiling in terms of advancement and ultimately doing a
disservice to your people.

------
rhoads
That's a conundrum that most developers who climb the chain face and the best
article I've read so far that comes close to answer it is this one:

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

Probably posted a billion times here since y combinator is just one of the
things that derived form the work of the master Paul Graham.

------
jspiral
Here's a lens I use to think about my job that might make sense to someone
with an engineering background:

\- I'm in charge of architecting and building the team. the team is a system,
of people and processes

\- the team has various functional and nonfunctional requirements which i
product manage

\- I surface how the team works in general to our stakeholders, and our team
strategy mainly deals with adjusting our "interface" and performance

\- I also surface our team's current plan and how we're tracking, to the
appropriate stakeholders, to give them context if we want to adjust how the
"system" works

\- I don't do any tasks other than those that relate to the above

\- I don't try to heroically post-process or supplement the machine's
performance through my personal efforts unless it's just really high leverage
in that situation. (would have to be live or die almost, otherwise not worth
it in the long run). I spend my efforts on adjusting the characteristics of
the machine.

------
dsr_
My job changed from doing all the things to (a) picking which things should be
done and (b) making sure that all those things get done.

We use a ticketing system that enforces a minimum amount of process and
otherwise stays out of our way (RequestTracker, highly recommended). I keep
the master project list in a text file. We have a weekly status meeting where
the master project list is 80% of the agenda. The meeting usually lasts about
30 minutes unless we have something particularly deep to discuss, design or
dispute.

We keep in close contact with our chat system, email, and in-person meetings
when people feel like they need them.

Every morning I review:

\- tickets generated by alerts. Did they get handled properly?

\- new tickets from users. Have they been picked up?

\- master project list. Does anything need _my_ expertise?

Throughout the day I look for signs that I should help people with their
tickets or projects. Occasionally that means solving the problem for them, but
usually it means pointing them to the right documentation or acting as their
rubber duck.

Another chunk of my time is spent in diplomacy with other people in the
company and sometimes with customers.

------
legohead
The path towards management means less coding, especially the higher you are.
VP/CTO/Director shouldn't be coding at all. Your job is managing the people
and tech, guiding, mentoring, hiring...

Startups, especially early ones, throw this all out of the water of course.
But once you hit 100+ employees the "real world management" starts to come
into play.

------
rb808
Are the people who work for you busy as well? I'm great at taking in all the
extra work and not delegating. Often its because the people under me dont know
how to do something - they should be able to figure it out, I'm just not good
at forcing them do it.

If they are busy you should focus on getting more resources - as well as
improving the productivity of the team.

------
chenning
Would you classify someone like Linus Torvalds as a manager _and_ an
individual contributor? I see a lot of obsession with pigeonholing and
defining roles with zero degrees of freedom. "A manager needs to stop doing
____ and needs to start doing ___". Who's making these definitions? I know
plenty of small business owners who are quite successful at wearing both hats.
I personally don't have a problem if someone out there decided that in order
to be an effective leader they have to abandon their previous responsibilities
entirely, but I don't see how that becomes a universal rule. Just because
everyone else is doing it doesn't make it right and no longer worth looking
at.

~~~
sidlls
About Linus: no; he's an architect.

The small business owner very likely has to wear more than one hat due to the
size of his staff. This discussion is in the context of an organization likely
much bigger than most small businesses of the kind you describe. The
organization is inside a company that is in turn bigger. I don't think that a
direct comparison useful.

~~~
stackdestroyer
Agreed - my situation is currently a team of 20, but previously up to 75 in my
org. I work for a mid-sized company that's ~2500 people in total.

------
tixocloud
What made you successful in the past may not make you successful today.

When I started to prioritize, delegate and only focus on key details, it was a
big shift in mindset but also a big boost in my effectiveness as a VP.

Know when to say things and when not to say things. Let go and think big
picture. You're in the business of delivering through your team and your role
is about giving direction to your team so their work is meaningful to them and
to the organization.

Not everything will need your attention - you mostly only need to know when
the project will be completed, help your team unblock roadblocks (in terms of
tech, process, people) and align all projects to the overall strategy.

------
segmondy
Delegate is the keyword. You have to trust and not worry about the details.
You can't be solving all the problems. I've had my reporting team come to me
seeking a solution, I tell them to go solve it and come with the solution. I
can review the solution and give a fast feedback if they still have concerns.
More often than not, when they think about it, they come up with what works.
The more responsibility I give to them, they more they step up to the plate
and start filling in those big shoes. Just 1on1s, business partner, vendor
meetings & daily status update is enough to fill my entire week.

------
_the_inflator
Cool question.

Basically, you don't manage your time. You use it. What are you trying to
accomplish, how many resources do you have?

There are goals, you set, and there are bottom-up driven innovations.

The feeling of being overwhelmed is a good one as long as drowning in ideas
not trouble. ;)

I try to have a decent team around me to help me get my goals done. The rest
is hard work, there is no happy path to leadership/management. Dealing with
VUCA is the price you pay. This is part of accepting being a manager. I read a
lot of good business books, talk to trusted colleagues and set timt to focus
on strategic topics.

Enjoy your career, learn and have fun with the people!

------
hsk0823
I think the Peter principle, the idea that people are promoted to until they
are incompetent in their roles, comes into play.

What worked for you to get to the job isn't necessarily going to work for you
to succeed in the job, I agree with others saying that it's not a time
management issue, it's a change in perspective that's require, you no longer
have the ability to do everything for everyone, you now have to lead people
you can trust to fulfill those tasks better than you could, as your
responsibilities grow, the rest of your team doesn't stay static, they also
grow with you.

------
codemac
1\. Your calendar is your new todo list, if it doesn't fit, get rid of it.
You're negotiating about your time. Review your calendar at the end of the
week to ensure you're putting in time on the projects you need to.

2\. You'll start to see why GTD got so popular, you need a list of things you
can do. GTD's Agendas & WaitingFor lists are for you.

3\. If you don't have an ea/admin you trust, you need to get on that. The best
chief of staffs I've ever worked with started as EAs. They should be able to
grow into HR, Finance, or Program Management, or chief of staff.

~~~
stackdestroyer
Diving in on GTD and have thus far really been converted. Having a system -
_any_ system, is critical. It became clear pretty quickly that my "system" was
just me using my head and brute-forcing my way through things.

------
ddebernardy
It sounds like you're not delegating enough. This is key when you're managing,
especially at a senior level. And not just technology-related stuff.

Pick two thresholds:

\- Maximum amount of time you're willing to allocate to a specific task.
(Example: 1h. FYI, David Allen of GTD fame recommends 5min for very senior
execs.) Try to delegate anything above that number.

\- Amount of time you'll take you to get it done vs amount of time it'll take
one of your directs or skips to get something done. (Example: a task that you
could do in 1h will require 10 man-hours if done downstream.) Pick a number
and try to delegate anything that requires less downstream effort.

When it comes to delegating, remember: back when you were an engineer or a new
manager, you sucked at what your boss was delegating to you, but you managed
to produce something that was good enough and you became better at it with
time. Your directs and your skips will learn too.

Also:

\- Learn how to hire. If you're managing managers you absolutely want
dependable directs who you trust will get done whatever stuff you delegate to
them. And frankly, the same holds when you're managing engineers. (As an
aside, a common mistake in early stage startups is to let the founders or HR
hire for you; you're going to be the one managing whoever gets hired, so push
back if you've no say over who gets hired.)

\- Put a weekly 30min 1:1 with all of your directs in your calendar if you're
not doing so already. It'll save you lots of interruptions because your
directs will know they've some time allocated for less urgent stuff, and it'll
allow you to surface incoming problems before they blow up in your face.

\- Ax the time you spend on email to free up your calendar. Pick 2 or 3 time
slots during your day. (Example: early morning upon arriving, before or after
lunch, and before leaving.) Block those slots in your calendar. Only do email
during those time slots. (Close your Email client and turn off notifications.
If anything's actually urgent, your phone will ring.) Also, create filters to
surface what's important and what's not. (Anything cc'd to you or not sent to
your email directly probably isn't high priority; stuff sent by your boss or
by your directs probably is.)

\- Block a few hours in your calendar to actually get your own work done. Part
of your job arguably is to be available, but if your calendar is wide open it
invites your coworkers to swamp you with meetings. And be picky with meetings.
Unless it's coming from your boss, refuse to join meetings that don't have a
clear agenda. (Send one of your directs instead.)

\- Build good-will and political capital in your organization. At senior
levels, I'll scratch your back if you scratch mine tends to count a lot. So
don't hesitate to spend a half hour every so often with other managers that
deal with stuff your teams have interaction with to catch up. (There's no
point in building a new product if the heads of marketing and sales don't both
think there's a market.) Don't confuse this with schmoozing, else your weekly
or fortnightly meeting will be first to get binned when calendar time is
scarce. But work on those relationships.

~~~
stevetodd
> Build good-will and political capital in your organization.

It’s very easy to overlook relationship building. Even just stopping by,
saying a quick hello, and giving a smile to execs in different departments can
make a world of a difference in how well your departments can work together.
This can make a big difference at whatever level you’re at in your career but
is especially impactful the higher you go up the ladder.

------
ssss11
Your tasks and projects are now high level politics and people management.
Give up thinking of technology, at all, you now have to maximise the value of
Your department to the business and the perception of your VP counterparts. I
found similar issues rising thru management and (I’m mid-career) have changed
roles to focus on what I enjoy rather than politics.

------
stackdestroyer
Thanks to everyone who took the time to add something to this thread. Lots of
valuable stuff in here, and I've got some rearranging to do with my
perspective, and how I think about my time and tasks. I'm sure I'll have more
questions, but for now I've got work to do to get better at this.

------
pete23
Delegate ruthlessly. Get a 2IC/COO to deal with running operations,
concentrate on strategy, people, ensuring your organisation is the right
shape, value add.

~~~
arethuza
When I was a direct report for a CIO of a fairly large multinational (40+
countries) my boss spent most of his time on the road travelling - he had a
gruelling job. He was completely hands off when to technology - although he
was actually fairly technical.

