I'm currently reading the book "Team geek". It's a small book and I would highly recommend you read it!
[deleted]
Ask HN: Switching from developer to project manager. What to keep in mind?
101–109 of 109 posts
Re: Ask HN: Switching from developer to project manager. What to keep in mind?
#102I'm currently reading the book "Team geek". It's a small book and I would highly recommend you read it!
[deleted]
Re: Ask HN: Switching from developer to project manager. What to keep in mind?
#103The job of a project or program manager is 100% influence based. In other words, you need to employ influence skills to get people to work on your priorities. There's a great book, Influencer, that spells out a procedure for determining how and when to apply a subset of skills that will help nudge your team in the best direction.
Re: Ask HN: Switching from developer to project manager. What to keep in mind?
#104Earlier quoted context omitted.
I think the difference here is between having responsibility vs acting like the guy with the crown. A manager should respect his engineers and shouldn't tell everybody that the engineers are "his guys" like he owns some slaves. But in the end he's the one who should be allowed to override an engineer's decision on whether to work on task A or task B, when to pull extra hours and when it's okay to slack a little. And…
> But in the end he's the one who should be allowed to override an engineer's decision on ... when to pull extra hours No way. I can agree that often the PM has the ability to set task priorities (not always, devs can push back and the devs' people managers will have the final say), but no way does a PM have the authority to decide that a dev should be working extra hours. Absolutely not. That is a pure people manage…
This is a great point. If there's a resourcing issue, it should be brought up on the project calls way before it's an actual problem.
Re: Ask HN: Switching from developer to project manager. What to keep in mind?
#105Earlier quoted context omitted.
> the title doesn't mean you're a people manager. You're the developers' peer This, 1000 times. The Project Manager role is one of convincing others, helping organize them, and smoothing out relationships with other teams/organizations. If you try to act like an authority figure, the devs working with you wind up in an "Office Space" style "I have 8 bosses" problem.
Some PMs wear at times the peer hat. However I believe it is not a good idea to consider yourself a peer. Confusion about roles can lead to conflicts. By design the PM has to have to last word in most critical decisions, especially with outside contacts and that makes one stand out. An important part of the PM role is to say "NO" to all sides - while a peer may say only "no" - and this requires power. How to achieve…
Having worked at some large corporations then have pmos and such. Yes, pm's are normally clased as peers. Devs normally report to a people manager. Pm's dont manage people.
PM's normally do their job via persuasion. They may get push back from the team on certain issues. Their job is report on this push back and the reason for it.
Re: Ask HN: Switching from developer to project manager. What to keep in mind?
#106Earlier quoted context omitted.
I think the difference here is between having responsibility vs acting like the guy with the crown. A manager should respect his engineers and shouldn't tell everybody that the engineers are "his guys" like he owns some slaves. But in the end he's the one who should be allowed to override an engineer's decision on whether to work on task A or task B, when to pull extra hours and when it's okay to slack a little. And…
I think you have correctly identified a class of decisions in which PM's should have the final say: ie. "What should the team be working on now" But equally there are a class of decisions in which developers ought to have the final say: "how should we implement this" and sometimes "which technology should we use" I think peer is about right. With an important caveat, that PMs are often ALSO people managers. But that…
I can agree with that perspective. Yes, the implementation details should be left to the engineers. And in that regard you could consider both peers.
Re: Ask HN: Switching from developer to project manager. What to keep in mind?
#1071. Don't take anything personally. 2. Always remain calm and patient. 3. When people make bad decisions against your strong advice don't feel the need to make their bad decisions a success. 4. Don't own the failure of people who don't understand software development. You'll always be doing the best you can with what you're given. 5. You'll be remembered for your grace and professionalism. 6. Never tell a lie. Never g…
Excelent list. Can you describe the "Never use the word should" a bit more in depth and give some examples?
Sometimes it's appropriate to use "should," such as "We should implement some kind of user authentication."
Other times, you'll hear someone say that their idea is the way it "should" (when they mean "must") be done, without regard to drawbacks, benefits, long term costs, or the need to treat their coworkers with respect.
"This should be done this way! Your way is just wrong." That kind of thing happens on some teams. Sometimes, they're right. The other way is just wrong. Some other times, it's jerk driven development.
Re: Ask HN: Switching from developer to project manager. What to keep in mind?
#1081. Don't take anything personally. 2. Always remain calm and patient. 3. When people make bad decisions against your strong advice don't feel the need to make their bad decisions a success. 4. Don't own the failure of people who don't understand software development. You'll always be doing the best you can with what you're given. 5. You'll be remembered for your grace and professionalism. 6. Never tell a lie. Never g…
Excelent list. Can you describe the "Never use the word should" a bit more in depth and give some examples?
Normative speech (often using the word "should") means "I have reason to believe". "Reason" usually being based on some a priori[0] knowledge.
"we should be able to do x with y"
"y should just work"
"users should be able to k"
In a problem space such as software, where extreme complexity bordering on chaos is the norm, we we see little evidence supporting common claims of an expected outcome given reason from some fashion of first principles.
"Rails should work just fine for this", given some principles about Rails.
The problem with the above statement is that you cannot possibly take into account the entire complexity of the final implementation of the appropriate solution beyond the most trivial example.
Marsh's first law of software: The complete behavior of any sufficiently useful computer program cannot be reasoned about by a human in polynomial time.[1]
Should is a smell. The only should I trust is a passing test.
Sorry if that's clear as mud. I've been working to come up with a good explanation for my "normative speech has no place in software" axiom and I'm not sure I've nailed it quite yet.
0: From Wikipedia: A priori knowledge is independent of experience, as with mathematics (3,000 + 2,000 = 5,000), tautologies ("All bachelors are unmarried"), and deduction from pure reason (e.g., ontological proofs).
1: Yes I'm referencing my own made up law. Prove it wrong.
Re: Ask HN: Switching from developer to project manager. What to keep in mind?
#109There is a great talk from Patric Kua.
He also has a book "talking with techleads" which reflects on the question that you have asked!