Ask HN: How to Hold Someone Accountable?

[adoga]

I'm a first time tech lead (CTO, but functionally more of a tech lead) at a start up and I've been struggling with the advice of "holding someone accountable".

My vision for culture was to use a KanBan process so that we could quickly iterate, be agile, and set up a sustainable workload. Mostly using Eric Brechner's "is this task less than 5 days?" to break work down and put it on the board.

So far this has worked out well for 3 developers on the team -- they work hard, communicate often, and really try to push the ball down the field every day. Code is checked in on a daily / every other day basis and overall have a high degree of "accountability" to work hard every day.

We brought on a senior backend developer in May who had previously worked at a bank for 10 years. He was meant to be a key hire to take over on some of my involvement with the backend codebase (note that I am not the original author, it was originally written by a previous contracting house). Overall I would describe him as "okay" -- has been slow on his tasks ("is this less than 5 days" = 5 days), overshooting timelines that he gives (everything is always "1 or 2 days away") , and "okay" quality.

- I'm a developer and understand that there is an element of "it takes as long as it takes", but I want to start thinking in days instead of weeks for tasks

- I had a 1-on-1 with him today and he describe it as "relaxed" which is definitely not how I've been feeling

I'm not quite sure what to do in this situation -- clearly there is an element of mismanagement on my end, but there is also an element of "this person is not driven like the rest of the team" that I don't quite know how to handle. How do you determine how much is your own failure as a manager, versus how much is someone just "not working out"?

- Do I just need to get really specific about asking "how long will this take" for every task and then trying to hold his feet to the fire when we get there? What does this look like?

    - "You said 2 days ago that it would be done in 1-2 days, what's going on?" What if they come up with excuses?

    - I have an agreeable personality which I am trying to overcome, and so am trying to figure out how to navigate conflict in a healthy way

Any help / resource recommendations would be greatly appreciated!

[codegeek]

"who had previously worked at a bank for 10 years"

This should have been your first red flag. No really. I run a small bootstrapped SAAS company now but in my previous life, I worked at Investment Banks for over 10 years. Nothing gets done fast at banks. Nothing. It is the culture and event the smartest people get used to it and become part of it. I quit because I literally had nothing to do or when I did, it took forever due to red tapes. I of course wanted to do my own thing but the decision to quit was so easy because I didn't like the pace at which things got done there and I wanted to move fast.

I don't know this person but based on what you said, it seems like they are bringing the same culture and experience to your team which clearly doesn't work at a startup.

I doubt they can change the way they are because they have been "institutionalized" (stealing a quote from the movie Shawshank Redemption). If you don't believe they are producing work at a fast enough pace and with decent quality, it won't change much by you talking to them. I hope I am wrong but my experience says otherwise.

This is what I would say is "culture fit" when looking to hire at smaller teams/startups. You hire someone from a bank ? You won't get the same level of urgency. Period. Unless they quit the bank to address that specific problem.

[allig256]

However, your own life trajectory contradicts the notion that this person is irredeemable. You yourself made this change!

I wouldn't be too quick to judge them off of their previous roles. Banks can be slow yes, but as with all companies, where you are in the company often plays a bigger role in you work than what company you're in.

[codegeek]

Yes but depends on why that person left the bank and joined the startup. I have hired a few people who came from similar backgrounds and they pretty much brought on the same work ethic which unfortunately doesn't work for smaller fast moving teams.

[tacostakohashi]

It sounds like the main issue with this person is a lack of transparency, and lack of collaboration.

If something is supposed to happen in 1-2 days, then after 1 day, there should be some signs of progress, like some specific questions/clarifications about the task, evidence that something is being run in a local environment, etc., and then after 2 days, it there should be a working PR, evidence that the code has been run, or alternatively some specific issues that that were hit, and specific details of 'this 70% is done, that 30% is not done', and specific action items for whats next, and not some vague one more day, one more day type thing.

The purpose of communicating specific details is to foster collaboration. The person may be on the wrong track, taking the wrong approach, other team members may have tips and suggestions, or at the very least have things to learn.

It may be that the 1-2 day task ends up taking weeks or months or whatever, but if thats the case there should be specifics that are communicated and artifacts that are produced as progress is made, not just endless 'nearly there, one more day'.

[adoga]

Thank you for the reply, I think that this hit the nail on the head for what I've observed in myself and the other devs on the team, and what I've been struggling with with this particular dev.

I understand that a 1-2 day task can end up taking weeks or months (and is really the culture I'm trying to create were we don't burn people out on the realities of software development), but I need more transparency and collaboration in the process (which the other developers have been doing without explicitly being told to do so).

I think that, along with making my expectations of speed explicit and giving him time to adjust is what I need to do to move forward.

Thank you

[lostdog]

If someone does not meet your expectations then you can fire them.

However, in my experience throwing around the word "accountable" is a clear sign of a bad leader. It's a way of shirking responsibility for the situation, and implying that the other person is failing in some basic moral way.

So hold your own damn self accountable. Take a beat to decide if your expectations are reasonable. Then tell him your expectations are that estimates are better and tasks get finished more quickly. Give him some time to try to achieve this, and if he won't or can't then fire him.

[adoga]

Thank you, I think that this, along with the below comment of needing daily transparency and collaboration is what I needed to hear

[Goosey]

If he is describing the work culture as "relaxed" this is an indication that you have created a culture of relaxed expectations. If this is not the culture you want to foster you need to hold feet to the fire more IMHO. But if you want a relaxed culture and accountability you can't have both!

[RayFrankenstein]

http://mikehadlow.blogspot.com/2014/06/heisenberg-developers...

[bequanna]

It sounds like he is a poor fit. Changing management style with an existing employee is going to be very difficult or not possible. How difficult would it be to find another employee to replace him?

[nittanymount]

guess, first, need to figure out why he does not deliver as promised?

- is he technical incapable of doing it, cannot figure out things, underestimate the effort? if he is not strong technically, you may want let him go not waiting longer... some senior dev maybe not as strong as written on resume...

- or it is issue with his work attitude? if no improvement with clear kanban/scrume process defined, may want to let him go... ha

[fpdavis]

I have had similar employees and sometimes they just aren't a good fit. But first, are you following all of the Scrum/Agile methodologies? Are you doing DAILY STAND UPS so the TEAM can help hold individuals accountable? Are you performing RETROSPECTIVES at the end of each SPRINT... you are doing short sprints right :) Is the team making the assignments (as they should) or are you? Also, get away from estimating in days and go with generic units, the Fibonacci Sequence would be my suggestion. Make sure the team is defining the tasks and voting on the effort required for each task. I would do this for a couple of months to let the team get into a flow and begin to learn how to estimate things. Then observer how your problem employee votes to see if they are particularly high or low and see how many tasks they complete compared to the rest of the team.

If after all of that there is still a problem, setup an End-of-Day meeting each day with the individual to go over what they accomplished that day... actually having them show you code, interface, documentation, something that they had accomplished that day. In collaboration with the employee setup reasonable expectations and goals that you (hopefully) can both agree on. If the goals are not met, write them up, rinse and repeat. After a couple of write ups suggest that they are not a good fit and should think about moving on, after three or so you should let them go.