[fatnoah]

> Individuals and interactions over processes and tools

Last year I joined a company as a VP of Engineering and the first thing I did was to look at all of the meticulously crafted Jira workflows for tickets moving from New to Done, and all of the state transitions in between. There was an amazing level of thought and craft put into those workflows.

I then completely obliterated them and just defined states and let any issue be moved into any state. There was much rejoicing and nothing lost from the process, since the teams regulated themselves to make sure things were documented, code reviewed, etc.

[tguvot]

ymmv. i was in similar situation and developers moved tickets to "terminal" states without actually trying to address issues, won't write documentation, etc.

so state transitions had to be added and gates put in place.

it's always joy to work with teams of adults who can self-regulate. but when it's not what you have...

as small example: i had 2 developers telling to vp of engineering that they not going to implement some functionality because they don't see the need in it. For record, this functionality was needed

PS. i described in more details below

[feoren]

> i had 2 developers telling to vp of engineering that they not going to implement some functionality because they don't see the need in it

Sounds like the VP of engineering needed to get his head out of his ass and listen to the people who actually knew a god damn thing about what was going on.

[tguvot]

i was actually the one who brought him. and if you will read below, it has more details

[zeroonetwothree]

Did you have a discussion with those engineers as to why they thought it wasn’t needed? Presumably there was a reason, it’s not always (or usually) the case that VP of eng knows more than the ICs.

[tguvot]

i had veery long discussions with them for few weeks or so. i was wearing multiple engineering hats. vp was technical and knew what and why was needed. vp was brought in for enforcement action when it started to become bottleneck for other teams. after VP performed "enforcement" they gave estimation of 3 people for 3 months of work. And they wanted to implement half of the requirements and not in a way that were specified.

I went to guy next room, his estimation was 1 week of coding and 1 week of unit/testing/integration/documentation. He ended up been the one who did it

the bottom line that they just didn't want to work. on different occasion same two developers during review of requirements literally said "but to implement this functionality we would have to write a code/work".

Just for a context, this was company where company had gifts for 20 and 25 years anniversary of employment. And this is company that makes software for living. (Not the blue company.)

PS. Just for a more complete picture, that company had "agile methodology department" that had developed internally sprint/ticket tracking system and wiki. those systems weren't linked so you couldn't cross reference things. Project that I was hired to do was given exception from many policies so I decided to get jira/confluence, which despite been universally despised here were light years ahead of what company had. In process I failed to get approvals from it, information security, agile and some other departments. At the end (after 3 months) general manger personally approved it and took personal responsibility for any breaches.

yet, 1 year later I got visit from internal audit who weren't happy that I spent money on system that duplicates functionality of existing system.

PPS. the really funny part, i interviewed with google and was asked to tell how i had organizational challenge or something and how I managed to overcome it. I told this story (about buying jira) and after doing it was asked if i could do something different. I answered that given organizational structure it was the only way to approach. Interviewers verdict was that I am not humble enough because I can't admit that something could be done differently. Hence i am not googley enough and therefor "strong no hire"

[boxed]

Your story doesn't make you look good however you look at it.

If you are correct about those devs, you failed because the correct way forward is to fire them. So you fucked up.

If you are incorrect and those devs know what's up, then you are the incompetent one.

I see now way you can come out of this story looking good.

[tguvot]

it wasn't possible to fire them. and i wasn't their manager. also, how those devs could be correct if they asked for 9 man/month and the one in next room did it in 2 weeks

[lamontcg]

You had bad engineers.

If you inflict all that process on any good engineers in your company because of the bad engineers, you'll probably chase them off and be left with only the bad engineers who need all that process to keep them in line.

And what is weird is that processes like those can get justified by the fact that they produce objective measures to terminate bad employees if the violate the process, but in reality its the bad ones that are going to hang around and put up with it passive aggressively.

[tguvot]

"bad engineers" were like 75% of project. Fortunately good one were mature enough to understand why those processes happened and didn't complain about it.

also, given company structure it was very hard to terminate anybody. so we were stuck with who we got. and we got for this project "the best and the brightest"

[lamontcg]

so scrum is a symptom of a company that nobody should want to work for.

[tguvot]

i personally was in company for 6 months. developers had 10-15 years seniority. those processes happened without any connection to scrum, but. this company had mandated scrum that was defined by agile methodology department which developed it's own scrum tracking tools (i made sibling comment about it).

scum-sprints were used in order to avoid making designs and chop things into tiny pieces that were taking entire spring to develop. sprint demoes were "faked" (same demo could be shown for months at a time or there will be no real functionality behind it).

i worked in different company where they hired senior vp of engineering whose resume on linkedin was full of "implemented scrum - improved delivery/quality/etc". so engineering went to do hard core agile, with sprints, demoes that were showing amazing progress and that we are on track for doing everything in time. day before release eng. manager went to him and let him know that nothing works and they need at least half an year to get to half of the defined scope (i warned him about it two months ahead, he told me that I crazy). story ends with C-level appearing on one of the all-hands, calling him aside for a chat. he was never seen again.

so yes, for me, mandated scrum is symptom of the company that I won't go to work for.

[PeterisP]

You describe valid problems that are reasonably frequent at many organizations, however, literally none of them get solved by a software tool being stricter at enforcing state transitions - all of them require the relevant managers to actually manage people.

[tguvot]

i absolutely agree. but... people were essentially unmanageable, borderline impossible to fire and there were no backfills at this period of time.

not in usa

PS. amusingly enough their direct manager didn't see this kind of management as part of his job

[mjfisher]

Did the enforcement of state transitions actually make a difference to the underlying work there?

In my experience, if there's a problem with the engineers then all of the process in the world won't fix it.

[tguvot]

it made a difference in preventing things from disappearing without trace. it's not a fun activity to dig through a bunch of closed/won't fix/not a bug tickets to figure out what is valid and what is not

[mjfisher]

Yeesh. I don't envy you there. Did they turn around in the end?

[tguvot]

no. but processes provided guard rails. i didn't enjoy it, but sometimes you have to work with what you have. you can't "reeducate" people in their 30s or 40s to be more responsible towards the work that they do.

interesting point though, it's the way that this company works it's that there is core r&d group that builds "framework products". those things never go to clients directly. they go through delivery groups that customize/extend them according to client needs. and fix bugs.

project that we build was the only one that was direct to client and many people simply couldn't grasp that they are now directly responsible for what client gets.