The Art and Science of Leading Projects | Hacker News Reader

The Art and Science of Leading Projects

teamgantt.com

149 pointsismyrnow20 comments

Not for me, but I do like that one of the sections is:

> 08 - Winning trust with communication

> Learn simple keys to becoming a better communicator and how to identify your team’s different communication styles.

Having experienced the pain of working somewhere where leadership tried to decree a single "right" method of communication for all developers that didn't jive with us at all, I don't take this for granted anymore.

In that case, management declared that in-person communication was so essential to the agile philosophy that all devs should be ok with being interrupted by anyone and at any time for the purposes of having a face-to-face chat (and WFH was not allowed unless sick). I now work somewhere where I don't see any co-workers in person on most days, and somehow we get tons more work done and stay in contact just fine. Weird how that works...

People constantly confuse communication with a lot of talking and collaboration with sitting in the same room or constant meetings.

good communication happens when there's good [shared] motivation

The book "Project Management for the Unofficial Project Manager" is a high-level but pretty complete introduction to project management. It has good examples from non-technical projects, such as rolling out a new health program in a hospital. It uses official terms from the Project Management Institute’s infamous "Project Management Body of Knowledge" (PMBOK) so information learned from this introduction can be carried over to more rigorous projects.

https://www.amazon.com/dp/194163110X/

Thanks, I think I might check this out. I have been toying with the idea of getting back into leadership. I hate seeing all of these people with terrible bosses.

All of my leadership experience is 1) outside of tech, and 2) not remote oriented. Now that I have some experience as a coder under my belt (~5 years), I'd love to get some training on remote leadership styles and perhaps lead a team and make something useful.

Step 1 is not using a gantt chart to create some illusory impression of knowing exactly how complex projects will unfold.

Eh, I would say creating one (or something similar) is a useful exercise to help break up large tasks and think more thoroughly about how to split work within a team. It also helps to highlight possible bottlenecks and is a useful visualization so everyone on the team is on the same page.

Agreed. I love gantt charts because they show where things have to come together. I rarely give time estimates when asked but I always ask when something is needed from me to not hold up other people.

Wouldn't that just be a dependency graph?

Yes, and drawing a dependency graph would be a useful exercise too, but I rarely see managers drawing either a gantt chart or a dependency graph.

What is the difference between a Gantt chart and a dependency graph?

Gantt charts typically have resource assignments and time estimates. Dependency graphs just say Bravo requires Alpha to be completed first (for example).

Dependency graphs can also be annotated with the resources required for each node or edge. Resources are estimated by summation, time is estimated by finding the critical path.

Gantt charts are a partial linearization of a dependency graph. People tend to fixate over the dates shown, allow schedule pressure to "correct" previous estimates, etc.

According to some early users of Gantt charts, they are a great tool for summarizing a plan, a terrible tool for developing and maintaining one.

I think problem is not creating gantt chart but impression of knowing exactly how complex projects will unfold. If you do this without creating gannt or any other chart you end up with the same result.

TeamGantt is a great help for planning, and this course is well worth doing.

In my team's recent planning of a major multi-month feature, TeamGantt tooling helped us plan, helped our leadership visualize milestones and goals, and helped our developers deliver on time and on budget.

your comment history luckily proves you are not a sock puppet :)

but this comment is still suspiciously smooth

and how does he know the course is worth doing since only classes 0, 1, 2 of 14 are released.

I had the same suspicions on first glance, but quickly realized he was referring to their web service, not the training.

People have a tendency to classify some what complicated tasks as art or science. Leading a project is neither science nor art.

I think we're at a place where using the phrases "Art of ...", "Science of...", and "Art and Science of ..." are not interpreted with the literal definitions of art or science in mind. Typically, in colloquial (as opposed to formal) writing, "art" comes with an understanding of "all the steps haven't been quantified and some intuition is involved" and "science" tends to be "here are the steps to take and the items to observe and the things to change in response."

So I disagree: there is Art and Science to, well, most things; including leading projects.

Reply on news.ycombinator.com