← Back to context

Comment by hansmayer

1 month ago

First off - please do not be offended by the following comment, there is zero bad intent in it and is only meant as a way of nudging you into a correct mindset about the problem you described. Based on your public profile, you seem to not have much in the way of hands-on technical background and I suspect you manage your team based on some set of scrum/agile techniques. It can work purely for project delivery I suppose. However for the deeper analysis of your team productivity, the problem is you don´t have the necessary competence to validate your suspicion about one of them not getting work done, coasting off of others etc. There is only two ways to go about it. Either you hire (or promote) a technical lead in your team, who can then actually make that call, or you learn programming yourself, accrue at least a year of real technical experience and then try to evaluate. I am saying this because I have seen people with background similar to yours usually struggle, because they try to infer something about engineer productivity based on various proxy measures, such as who talks the most in the chat, who has most commits or even based on activity in Confluence. The way I would recommend any scrum master/PO/agile coach/MBA to think this dilemma is: you would not be able to judge the quality of work of a medical doctor, lawyer or a mechanical engineer, without having a similar background, experience and competence. So what makes you think you can evaluate software engineers without the same preconditions?

9 comments

hansmayer

Reply
bberenberg  1 month ago

I think lots of the other comments are making wild assumptions leading to responses that don’t align with reality. Yours is actually the absolutely correct one. I agree with the solution wholeheartedly. The only difference is I have been trying to promote the tech lead from within vs hiring externally. I want the team to know that we value their contributions and that we’re going to do everything we can to promote internally. I have various challenges with this internally related to seniority, language skills, etc but I’m working to resolve that.

But in the meantime, I still have a team to manage.

rvba  1 month ago

One of the members of the team is barely doing anything and survives by constantly asking others to help with doing the job. This reducea productivity of other employees.

A known archetype in many jobs, not only programming.

Yet we get comments like this:

> you don´t have the necessary competence to validate your suspicion about one of them not getting work done, coasting off of others

Wow.

In any other job, a manager ir HR will just read your chats, emails + demand to document calls - and guess what. It can be found. In a very not very subtle way.

Also the problem above is like managememt 101? For all the talk about "no technical competence" you dont seem to have any managerial competence.

Also the agile idea that developers keep each other to professional standars is a nice fairy tale (like whole agile in general).

  • hansmayer  1 month ago

    Sorry but what is your point? I feel like you got offended by identifying yourself in it, but did not really understand it. My point being, as a non-engineering manager, you can be great at 1) approving holidays 2) doing a bit of project management 3) doing formal 1:1s . But it does not mean much because you don´t understand the work being done and you are just doing performative actions, e.g. busywork. Or we just say, f*ck it, let MBAs and scrum masters keep running our critical engineering businesses and at the end of the day the doors fall off of Boeing airplanes and astronauts end up spending 9 months instead of 9 days in space.