1. 13

What advice would you give a first time manager? Specifically I’m interested in your thoughts on the following areas/topics:

  1. 1-on-1 meetings w/ team members in regards to content/agenda and frequency (once per week, once every 2 weeks, etc…)
  2. Staying relevant by continuing to code and handle tickets/bugs/features on the product (i.e. “staying in the weeds”)
  3. Time management advice
  4. Helpful resources (books to read, websites, courses to take, etc…)
  5. Maintaining/Promoting culture
  6. Hiring advice
  7. Retention advice
  8. Performance evaluations and career planning
  9. Increasing quality and productivity
  10. Adopting the 20% free time idea to spawn innovation and encourage creativity / have fun

But in general: What have you seen an excellent manager do, and therefore would be good habits to emulate? Flip-side, what should a manager avoid doing?

  1. 10

    Apologies if this formats poorly:

    • 1 -> Let the team member determine timing. You don’t want a meeting that is compulsory which is seen as a time sink.
    • 2 -> Your job is no longer to code / perform technical things (aside from traffic management). Your job is to make your team members better and let them do their jobs. That means you should be pushing back on product management and helping your team to do what makes sense. You can still do some technical things by (for example) performing code review and design review (to help improve your team); however, it’s probably more helpful to your team to let them do their jobs and eliminate obstacles.
    • 3 -> Always be on time to things. If you’re late that means whoever you’re meeting with is not important.
    • 6 -> Keep your hiring bar high. Period. Once you let your bar down to just “get things done” you are admitting that you are choosing faster and cheaper over high quality (in the infamous triangle of faster, cheaper, quality…pick two). When you hire to get things done, you are incurring talent debt.
    • 7 -> Retention is more important than hiring IMO. The folks you keep are the ones who are determining your culture. The people you hire are the people who change your culture. It’s also typically cheaper to retain people than to hire people.
    • 8 -> I don’t believe in once a year formal performance reviews as they commonly exist. I would rather have 360 reviews with my folks every 6 weeks or so. Here’s where I think you’re doing very well. Here’s where I think you can improve. Here are a couple concrete things you’ve done recently and how I feel about them (good or bad). Now let’s talk about how I am performing for you…or how you feel others can improve/are doing well. I like to think of it like the agile world. I’d rather things being iterative as opposed to “Remember that project you worked on 9 months ago…here’s what you did wrong there.”
    • 9 -> Increasing whose quality and productivity? Yours? Your team members? Your entire teams? Those all require different tools and appraoches. The only thing I’ve done a lot recently which I feel like most places don’t do is pay down technical debt on a regular basis (be it 1 week per month or 1 out of every N sprints, etc.) Schedule it and do it. Otherwise, I feel there tends to be a lot of lip service to paying technical debt and not enough doing of it (until it becomes much larger than it needs to be)
    • 10 -> I like the 20% time but I’ve never been able to do this well. Closest thing was a sprint every N which was “a free sprint”. It wasn’t as successful as I wish it had been. I’d love to hear how people do this well (and not just the 2 day hackathon every quarter like some places do).
    1. 1

      1 -> Let the team member determine timing. You don’t want a meeting that is compulsory which is seen as a time sink.

      I disagree with this sentiment. 1-on-1’s are really important and a lot of people either won’t own up to wanting them or won’t realize how important they are. Making it a regular thing (ours are every 2 weeks) means someone doesn’t have to feel weird or out of place asking for a meeting with their manager. I think a lot of people don’t naturally feel comfortable doing that and a regular, compulsory, meeting makes it much easier.

      Most people won’t tell their manager what is on their mind naturally, you have to force it out of them.

      1. 2

        While I agree that it’s easy to underestimate the value of 1-on-1’s as an engineer being managed, it is valuable to give the engineer some input in what frequency is ideal. It helps to make clear that 1-on-1’s don’t need to be super-structured if there is not much to talk about, just grabbing a coffee some weeks and talking about the family can be just as nice as airing complaints about peers or blockers on other weeks.

        As a manager, there is a lot you can glean from casual conversation with your direct reports—about their happiness, productivity, ambitions.

    2. 8

      This is from a programmer’s perspective: for me, the number one thing I look for in a manager is a clear vision for the company/their department.

      “Dave” was the best manager I ever worked for. He understood the company from top to bottom - he knew where the business was going, and placed a ton of focus on making that clear to every one on his team. All of our goals matched his, and his goals matched senior managements, etc. Even though the rest of the company was a relatively turbulent place he managed minimize surprises and this lead to him having a ridiculously loyal team. I knew at least one programmer that took a pay cut to work with him.

      Conversely, “Tim” was the worst manager I ever worked for. He was a programmer converted to a manager, and even though he’d been a manager for ~15 years it was still a trainwreck. Most of our time was spent trying to “jump at opportunities” (chasing $$$), trying to insert the department into perceived weak spots in the company, etc. This meant what we worked on could change from day to day - literally “oh, that project got spiked, now we’re all pushing to finish (this other one)”. And since he decided his deadlines could not slip, we churned out crap code to move on to the next thing. The best programmers didn’t stick around for long.

      (names changed to protect the guilty!)

      1. 3

        I’m an IT manager with more than ten years of experience:

        (1) 1-on-1 meetings must be mandatory. With junior employees weekly meeting may make sense, but with senior people a monthly meeting may be enough. The important thing is the frequency should be decided by the manager, not by the employee. Personally I think 1-on-1 should be more about professional general issues rather than projects (this is already covered in project governance or day to day Project Management). Meeting should be about things like raises, corporate culture, company changes, facilities issues or even family problems that may affect work.

        (1b) If the team works in different projects (PM or consultancy) I like to have a weekly conference call/meeting (1h) with all the team so they know each other and can share experiences. Something like a mandatory chat in the water cooler.

        (2) This is ‘orthogonal’ to the manager task. If you want to be in coding, please do it, but remember this is not your main responsibility. You’re expected to solve problems and to make things move forward: chase people, do phone calls, organise meetings to clarify problems, tell and remind people what to do… It is ok to code, but never put your name as the owner of any programming task.

        (3) A really difficult one. Start with 1 third managing your team (or internal clients), 1 third managing your boss and 1 third administrative tasks. Adjust as needed. Remember that managing your boss is hard work and one of your tasks.

        (4) Select an older manager you admire and learn from him. Invite him for lunch, share your doubts. You’ll need a mentor, so find one. If the relationship with your boss is really good, let your boss be the mentor, otherwise find another person. I recommend someone older than you and from a different area (non IT would be great). Read Becoming a Technical Leader: An Organic Problem-solving Approach by Gerald Weinberg

        (5) The weekly call I described in (1b) is important. Also applying corporate values is important (sometime they seem cheesy, but in the day to day work people usually forget ethics). If your team has enough knowledge, create a quality improvement team with people with different skill sets and try to involve not IT people.

        (6) Hire based on how the person will fit in the team and his professional objectives (this does not apply for hiring managers). Check his expectations on company culture matches with your company corporate culture.

        (7 and 8) Be hard but fair when evaluation your team. They’re not your friends and they represent you in front of the company. You want the best possible team.

        (9) What they say in factories is also true in developing: Invest in process improvements and machinery upgrades. In IT and engineering we like our management to be coherent with the strategy. Not so much in other industries.

        (10) I prefer not to answer this one, but I would say only if it makes financial sense.

        *edited to add a book

        1. 3

          What follows is basically a rant about everything that’s wrong with a bad manager from a worker-bee perspective, not everything will be applicable to you but just take whatever you find interesting from this. Thanks a lot!

          Read “The Mythical Man-Month”, some managers still don’t get that you can’t grow a baby in 1 month by impregnating 9 women.

          When you consult someone technical for advise on something not your area of expertise, don’t just blanket accept the advice but try giving someone equally or more knowledgeable the premise and conclusion to test if it’s sane. Make sure no one suspects any trust issues, it’s just to avoid the whole “gee, hadn’t thought of that” situation.

          Don’t lose your cool, ever.

          Sometimes the best way to do a task is to not do it at all, the onus should be on the manager to figure that out.

          If you disagree with someone, let them have their say before you judge. Don’t be too quick to dismiss someone.

          Make your time as worthwhile as possible, a good manager has this trait and can inspire his team to do the same. Don’t just assume others can automatically do this (or can be trained to do this in a day), but rather lead by example (and care to explain yourself).

          Stay top dog. You need your metaphorical weight to boss people around, and you don’t need to be a d*ck to do this either. But put people on a pedestal and suddenly everything is jeopardised. Compliment peoples output, not how they produced it (maybe if it’s extraordinary but don’t let their ego become any bigger than yours).

          Provide people with context, it’s good to see how things fit into the bigger picture and makes the work seem more worthwhile (and thus exciting).

          Recognise people who are often used for consult may require more time to complete any given task.

          Ask people what they’re good at, often they’ll tell you whether they like doing that as well. Ask or gauge what sort of task they’re not as proficient with compared to their co-workers and try to not make them do those things. Also don’t make it known what your findings are, because that messes up the team spirit.

          1. 2

            1-on-1 meetings initially to get to know your team - and then as appropriate - which will depend on many factors. The best managers set goals and let their teams get on with the work, giving support and assistance as necessary, but avoid micro management. Personally I am a great believer in leading by example, and never get your team to do something that you would not do yourself. Finally, there are plenty examples of poor management - learn not to repeat the mistakes of others :~)

            1. 2

              I will second the advice to stay out of the code. But I would develop a relationship with a team lead and discuss with them the current state of technical debt, etc.

              You can test the product and file bugs. Certainly review bugs and keep track. But you are not in the code.

              There was a time when I would have wished for a coding manager. With a little more experience, I think what I wanted was a manager who could code, and therefore understood my challenges, but it’s too easy to engage in driveby micromanagement if you’re too close.

              Something off the wall: rotate your schedule. I’ve always had managers who were morning people, and I was not. This made catching them for a quick chat difficult because they would run out the door at 5. Come in early a few days, come in (and stay) late a few days. Your midday will be all tied up with meetings, so the best way for people to reach you is outside then.

              1. 2

                In my experience, your primary goal is to preserve your team’s ability to be creative and deliver. That means managing the agenda of people of you such that it doesn’t touch your team. It also means giving your team the freedom to do things how they want as long as you and them agree to when they need to be done.

                1. 2

                  Number 10 is nice in theory, but unless you’re a C-level with authority to institute it company-wide, it usual ends up turning into 120% time.

                  1. 2

                    Being a good manager is being invisible. Then again I’m the type that is for workplace democracy (read socialism).

                    Maybe be a facilitator for democratic decision making?

                    1. 1

                      2) Doing some work is fine, but don’t allow yourself to become a blocker, and make sure to leave the most rewarding work for your team.

                      4) I’m a big fan of First, Break all the rules It’s evidence-based, and it provides great foundational perspective. My boss gave me a copy of it, and I remain grateful.

                      6) Nearly every stage of hiring is harder (and more time-consuming) than I would’ve guessed before I was a manager. Treat it seriously or you’ll end up with an undersized team and/or bad hires.

                      10) I prefer organized hack days to 20% time. If something interesting comes out of the hack day, it can easily be promoted to a real project.