Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I learned after managing a small team for 2 years

luispcosta.com

Post reply on HN
Print view View original

21–30 of 102 posts

Re: What I learned after managing a small team for 2 years

#21

Post by mgl »

lylejantzi3rd wrote: post #3

> Documentation is everything What I learned after managing a small team for 2 years is that documentation is only good if the team can find it, if the team bothers to look for it, and if the team takes the time to read it. I can't tell you how many times I've linked pertinent documentation in Confluence from the Jira task, only to have the developer ignore it. What black magic do you have to cast to get devs to look…

Spot on points.

Documenting your work seems to be a lost art nowadays in many teams, yet it still is something tangible which we left during our work just next to the source code.

We just recetly posted a short text on how we do it at Stratoflow:

https://stratoflow.com/writing-software-documentation/

Re: What I learned after managing a small team for 2 years

#22

Post by lordnacho »

dakiol wrote: post #15
lylejantzi3rd wrote: post #3

> Documentation is everything What I learned after managing a small team for 2 years is that documentation is only good if the team can find it, if the team bothers to look for it, and if the team takes the time to read it. I can't tell you how many times I've linked pertinent documentation in Confluence from the Jira task, only to have the developer ignore it. What black magic do you have to cast to get devs to look…

> What black magic do you have to cast to get devs to look at the documentation? That's not how documentation works (in my experience). Ignoring documentation is fine (perhaps I don't need documentation to get things done?). The problem is having the need of documentation and find that none exists; that's the real issue. If there's no documentation, as an engineer I have 2 options: a) read the codebase, b) ask around…

It's not just whether it exists though. Too much documentation is a thing as well. In a way it's worse, because the reader can't find the thing they are looking for, but the author can always point at where it is when asked.

So then the author becomes the index and wonders why they keep getting asked.

Re: What I learned after managing a small team for 2 years

#23

Post by dasil003 »

tacker2000 wrote: post #11
ilrwbwrkhv wrote: post #8

> Agile is not always the answer can be generalised to: Agile is never the answer.

So whats the answer?

Individual agency granted in proportion to expertise. If the ambitions exceed the teams expertise than no process will save you.

Re: What I learned after managing a small team for 2 years

#24

Post by rented_mule »

ozim wrote: post #16

Agile is not about sprints or ceremonies that is SCRUM. Sprints don't have to be 2 weeks or more - if stuff changes weekly you do weekly sprints. I just fail to see how one can build anything if priorities change on a daily basis. Most of the features I work on take 2 days at least with 3-5 days most. I can see how one might need to change priorities once a week because you see bunch of stuff built get someone to che…

> I just fail to see how one can build anything if priorities change on a daily basis.

I experienced something like this in a startup where I was one of five engineers. We were lucky to have individual offices at the end of a hallway. The CEO would walk down the hall a couple of times a week, stopping in each office, and change priorities on us. He had no idea how disruptive it was and always laughed when we told him.

Eventually the CEO saw that we were making very little progress, but attributed it to lack of engineering management rather than priority churn. He was absolutely right, because part of management is managing up. Luckily he hired someone who was great at that.

The new manager spent time talking to each of us about our frustrations and then watched everything for a few weeks. He then realized that the priorities were going in circles - every few weeks the CEO would get back to the priorities from a few weeks earlier. So, whenever the CEO changed the priorities, the manager would say "we're on it" and not tell any of us. It took us a while to figure it out, but he'd also stall our releases until the "new" priorities lined up with what we were ready to release. Both productivity and morale sky-rocketed. And the CEO was happier than ever. I worked with the same manager in two other companies in subsequent years - I never felt as productive under anyone else.

Re: What I learned after managing a small team for 2 years

#25

Post by akomtu »

lylejantzi3rd wrote: post #3

> Documentation is everything What I learned after managing a small team for 2 years is that documentation is only good if the team can find it, if the team bothers to look for it, and if the team takes the time to read it. I can't tell you how many times I've linked pertinent documentation in Confluence from the Jira task, only to have the developer ignore it. What black magic do you have to cast to get devs to look…

Most documentation is poorly written, outdated and disrespects readers' time. However, imagine if every paragraph, every page, every document, would have to be prefaced with a brief summary? It's a small culture shift, but it would make a big difference.

Re: What I learned after managing a small team for 2 years

#26

Post by sanderjd »

lylejantzi3rd wrote: post #3

> Documentation is everything What I learned after managing a small team for 2 years is that documentation is only good if the team can find it, if the team bothers to look for it, and if the team takes the time to read it. I can't tell you how many times I've linked pertinent documentation in Confluence from the Jira task, only to have the developer ignore it. What black magic do you have to cast to get devs to look…

Pretty simple, really: Put it in the code.

If it is too big to go entirely in the code, summarize it in the code and then link to the full docs (ideally in markdown files inside the repo).

Another thing, which you can't really fix yourself, but which I'm still gonna shout into the ether: Ideally you have a browser-based code browsing tool, like GitHub or Gitlab, but one that actually lets people click through method calls into their definition. In my view, that's really the only sane way to read documentation outside of an IDE.

Re: What I learned after managing a small team for 2 years

#27

Post by abacadaba »

TylerE wrote: post #7
gumballindie wrote: post #2

"Agile is not always the answer" This ^^ is the sign of a future good manager.

The way it's typically applied these days, I'd go much farther. Capital A Agile is often not only not the answer, but the problem .

literally just stop the stupid meetings interrupting every workday other than maybe standup and grooming and then get out of our way and watch productivity improve /rant

Re: What I learned after managing a small team for 2 years

#28

Post by ericksoa »

The guy seems pretty earnest about this, seems like it is literally his first blog post.

It would not shock me in the least if people work in an org where they say they are "going agile", takes them through training where some Scrum Salesman conflates agile with scrum, leading to observations like "agile doesn't deal with change fast enough"

Honestly, we need a new word for it at this point.

Re: What I learned after managing a small team for 2 years

#29

Post by azangru »

> But most of all, agile doesn’t fit in the context of this particular project, because the client changes priorities very frequently.

The whole point of agile software development was to make it possible to adapt to an environment with frequently changing requirements. The hint is in the name — agile. How can "very frequently changing priorities" be a factor against agile software development is completely beyond me. "Agile" doesn't mean "scrum done badly", if that's what he is implying.

Re: What I learned after managing a small team for 2 years

#30

Post by epolanski »

lylejantzi3rd wrote: post #3

> Documentation is everything What I learned after managing a small team for 2 years is that documentation is only good if the team can find it, if the team bothers to look for it, and if the team takes the time to read it. I can't tell you how many times I've linked pertinent documentation in Confluence from the Jira task, only to have the developer ignore it. What black magic do you have to cast to get devs to look…

Jm2c but I find placing documentation outside codebases unavoidably a failure.

Doesn't keep up. I would include product documentation too.

Post reply on HN