6 ms·

I once read a HN comment that I cannot find anymore but said: “my default loop is "First, cycle through all my developers and make sure that I have equipped th

I once read a HN comment that I cannot find anymore but said: “my default loop is "First, cycle through all my developers and make sure that I have equipped them to be happy and productive in their jobs. Second, find something to do. If possible, delegate it; if not, do it. Repeat."” My biggest productivity gain was when I realized I should measure my productivity through the productivity of my developers. By the same calculation as done by the author I can only increase my own productivity so much but when I do the same for all my developers that adds another layer of multiplication. This means I regularly enter the office and don’t even turn on my laptop (monitors) before checking if any of my developers need my help. Helping them be productive is my first priority. When nobody needs my help I pick up a task from my todo list but only if I cannot delegate it or it is a short task. I try not to pick up any task that is critical for my developers progress because my days do not have enough focus time to work on the same topic for more than 30 minutes to an hour without interruption. This does not mean I do not take focus time sometimes, I do, but usually this is for getting my state of mind documented so I can share it with my developers and ask for their input to improve or reshape it. This helps again to have everybody understand the bigger picture so they can be more productive without my direct help and make decisions without requesting my approval. Also, because everybody involved contributed to the vision it feels better to work on it for all of us. The same holds for meetings. If somebody requests my attendance in a meeting I request the agenda of the meeting and if the request is valid I’ll join as helping to unblock multiple people is important. If I’m not the right person I point them to the person they need to get into that meeting. So, in short, I devote my time to helping my devs get 10% more done everyday and 1% better each year because that scales way better than just improving my own. (Though you could say that also improves my own?)

teej 9y ago
"As a CTO, my default loop is 'First, cycle through all my employees and make sure that I have equipped them to be happy and productive in their jobs. Second, find something to do. If possible, delegate it; if not, do it. Repeat.'" - tkiley https://news.ycombinator.com/item?id=3408449 https://news.ycombinator.com/item?id=3408449
- abhiminator 9y ago
  Thank you for digging up the link, appreciate it.
- darepublic 9y ago
  That sounds heavenly
segmondy 9y ago
From one manager to another, if you haven't read it. Get a copy of "High Output Management"
- bastijn 9y ago
  Thanks. I put it on my reading list for this summer.
- themarlzy 9y ago
  Thanks for the suggestion, just picked it up
rootusrootus 9y ago
I so need to figure this out. I just became a manager a couple months back and it's a constant struggle to avoid defining my success by what I do myself.
- bastijn 9y ago
  It is not easy to change your habits. I can only share what helped me most to transition to what I do today. I was lucky that I got my role about 2-3 months before the yearly review at which time I got the (anonymous) feedback that developers felt I was not available enough to support them. I remember at the time I responded with the natural reaction of somebody who newly obtained a lead position, I balanced the feedback against all positive feedback which was on the technical front (proven to work architectures defined, technical achievements, technology assessments, etc.). I also said I was available they just needed to ask. My manager carefully explained that indeed my skills as a technical engineer were phenomenal, but they already were before I got the role of architect and everybody knew this. The problem for him was that I don't scale and he couldn't clone me. The only option for me to scale beyond what I already did was to scale through people. This means for him teams signalling they were blocked because I wasn't available were major. Availability did not mean me sitting at my desk, it meant the developers would not feel blocked because of me. No matter the reason. He made this an objective for me. The next year I actively worked on this. As you, I struggled letting go my old behaviours. Right up to the moment of the next feedback round mid-year I felt I was not as productive as before. I spent hardly any hours on what I thought was "actual work" (i.e. having my code editor or enterprise architect open) but instead was coaching and instructing or attending meetings discussing issues or designs, or issues with designs. I felt sometimes I did not have enough time to spend with a single person to completely go over the issue at hand. What completely changed that feeling was the mid-year feedback I got. Literally every team reported very positive feedback on my availability. They felt empowered and trusted by me only guiding them (whereas I felt I didn't give them the complete picture). At this mid-year my manager discussed the "seven levels of authority" [0]: (1) tell, (2) sell, (3) consult, (4) agree, (5) advise, (6) inquire, (7) delegate. Where the scale is an increasing level of authority owned by the team or individual. He explained that every individual, and at larger scale every team, is on a different level of authority and I would need to recognize their current level of authority and gradually increase it as their experience grows. The last half year I kept running my routine of my earlier comment and in addition started paying attention to the signals that belong to the different levels of authority. You quickly notice some people you need to check-up on more often or even co-develop/co-design for a part whilst others have enough from a 30 minute meeting. You also notice some people rather spend 3 days struggling through code than ask a question whilst the latter would help them do the work in half a day. By pro-actively checking up on those people you make sure not to miss those opportunities. The end-year review was again positive, this time not only from direct feedback of developers but also from team-leads who reported their team members competencies were growing/increasing. Our project dashboards (agile) reported less blocked tasks and more throughput. In the end nothing can help you change as fast as getting (positive or negative!) feedback. If you struggle it might be good to request something like a 360 feedback (anonymous feedback from direct colleagues on all layers of the hierarchy). See where you stand. Together with your manager figure out actions to remove the negative feedback and improve the positive, and act. In 6 months to a year do the same and see where you stand. P.s. Let your manager know you struggle. I suspect my manager acted upon my struggles and made sure the team (competency) leaders of respective teams also let their developers know that they should not feel bad about requesting help, even when I looked busy. P.p.s. bit of a long story without too much structure but I hope it brings you anything :). [0] Mangement 3.0: https://management30.com/ https://management30.com/ (didn't like the book too much but it has its parts).
baxtr 9y ago
One core element how I measure the performance of my managers is how they maximize the output of their teams. That’s obviously good for two reasons. First, we will reach our goal faster and second everybody is more happy, because everyone is dreadful when they’re unproductive
ybalkind 9y ago
Have you got experience or thoughts about the remote working equivalent of "cycling through" your team? Cycling through implies (to my mind) casually being around your team, checking in, and helping where needed. Working remotely its a bit trickier? My team and I dont use slack or other chat platform, so for me to check in would require calls, meetings, emails etc, which is a bit more formal and disruptive then "cycling through".
- ndh2 9y ago
  A better way would be to schedule regular 1-on-1 meetings. You're not going to find out if somebody is happy by "casually being around".
  - themarlzy 9y ago
    Definitely recommend both. Casual ring around (for remote staff) and being present, coupled with feedback and understanding needs in 1:1
- bastijn 9y ago
  Being remote complicates things indeed. If your teams have daily stand-ups make sure to join and pay extra attention to language used. Complaints, sighs and tasks taking longer than initially estimated are indications they need help. Pay attention to code reviews if you have them and see if they are in line with your vision of the architecture if you are a software architect. If you have webcams watch for body expressions. That are some things that readily come to mind. Probably you can find more if you think about it a bit longer.

teej 9y ago

"As a CTO, my default loop is 'First, cycle through all my employees and make sure that I have equipped them to be happy and productive in their jobs. Second, find something to do. If possible, delegate it; if not, do it. Repeat.'" - tkiley https://news.ycombinator.com/item?id=3408449 https://news.ycombinator.com/item?id=3408449

abhiminator 9y ago
Thank you for digging up the link, appreciate it.
darepublic 9y ago
That sounds heavenly

segmondy 9y ago

From one manager to another, if you haven't read it. Get a copy of "High Output Management"

bastijn 9y ago
Thanks. I put it on my reading list for this summer.
themarlzy 9y ago
Thanks for the suggestion, just picked it up

rootusrootus 9y ago

I so need to figure this out. I just became a manager a couple months back and it's a constant struggle to avoid defining my success by what I do myself.

bastijn 9y ago
It is not easy to change your habits. I can only share what helped me most to transition to what I do today. I was lucky that I got my role about 2-3 months before the yearly review at which time I got the (anonymous) feedback that developers felt I was not available enough to support them. I remember at the time I responded with the natural reaction of somebody who newly obtained a lead position, I balanced the feedback against all positive feedback which was on the technical front (proven to work architectures defined, technical achievements, technology assessments, etc.). I also said I was available they just needed to ask. My manager carefully explained that indeed my skills as a technical engineer were phenomenal, but they already were before I got the role of architect and everybody knew this. The problem for him was that I don't scale and he couldn't clone me. The only option for me to scale beyond what I already did was to scale through people. This means for him teams signalling they were blocked because I wasn't available were major. Availability did not mean me sitting at my desk, it meant the developers would not feel blocked because of me. No matter the reason. He made this an objective for me. The next year I actively worked on this. As you, I struggled letting go my old behaviours. Right up to the moment of the next feedback round mid-year I felt I was not as productive as before. I spent hardly any hours on what I thought was "actual work" (i.e. having my code editor or enterprise architect open) but instead was coaching and instructing or attending meetings discussing issues or designs, or issues with designs. I felt sometimes I did not have enough time to spend with a single person to completely go over the issue at hand. What completely changed that feeling was the mid-year feedback I got. Literally every team reported very positive feedback on my availability. They felt empowered and trusted by me only guiding them (whereas I felt I didn't give them the complete picture). At this mid-year my manager discussed the "seven levels of authority" [0]: (1) tell, (2) sell, (3) consult, (4) agree, (5) advise, (6) inquire, (7) delegate. Where the scale is an increasing level of authority owned by the team or individual. He explained that every individual, and at larger scale every team, is on a different level of authority and I would need to recognize their current level of authority and gradually increase it as their experience grows. The last half year I kept running my routine of my earlier comment and in addition started paying attention to the signals that belong to the different levels of authority. You quickly notice some people you need to check-up on more often or even co-develop/co-design for a part whilst others have enough from a 30 minute meeting. You also notice some people rather spend 3 days struggling through code than ask a question whilst the latter would help them do the work in half a day. By pro-actively checking up on those people you make sure not to miss those opportunities. The end-year review was again positive, this time not only from direct feedback of developers but also from team-leads who reported their team members competencies were growing/increasing. Our project dashboards (agile) reported less blocked tasks and more throughput. In the end nothing can help you change as fast as getting (positive or negative!) feedback. If you struggle it might be good to request something like a 360 feedback (anonymous feedback from direct colleagues on all layers of the hierarchy). See where you stand. Together with your manager figure out actions to remove the negative feedback and improve the positive, and act. In 6 months to a year do the same and see where you stand. P.s. Let your manager know you struggle. I suspect my manager acted upon my struggles and made sure the team (competency) leaders of respective teams also let their developers know that they should not feel bad about requesting help, even when I looked busy. P.p.s. bit of a long story without too much structure but I hope it brings you anything :). [0] Mangement 3.0: https://management30.com/ https://management30.com/ (didn't like the book too much but it has its parts).

baxtr 9y ago

One core element how I measure the performance of my managers is how they maximize the output of their teams. That’s obviously good for two reasons. First, we will reach our goal faster and second everybody is more happy, because everyone is dreadful when they’re unproductive

ybalkind 9y ago

Have you got experience or thoughts about the remote working equivalent of "cycling through" your team? Cycling through implies (to my mind) casually being around your team, checking in, and helping where needed. Working remotely its a bit trickier? My team and I dont use slack or other chat platform, so for me to check in would require calls, meetings, emails etc, which is a bit more formal and disruptive then "cycling through".

ndh2 9y ago
A better way would be to schedule regular 1-on-1 meetings. You're not going to find out if somebody is happy by "casually being around".
- themarlzy 9y ago
  Definitely recommend both. Casual ring around (for remote staff) and being present, coupled with feedback and understanding needs in 1:1
bastijn 9y ago
Being remote complicates things indeed. If your teams have daily stand-ups make sure to join and pay extra attention to language used. Complaints, sighs and tasks taking longer than initially estimated are indications they need help. Pay attention to code reviews if you have them and see if they are in line with your vision of the architecture if you are a software architect. If you have webcams watch for body expressions. That are some things that readily come to mind. Probably you can find more if you think about it a bit longer.