So, what should I do/learn ? Is there any roadmap/checklist for a programmer ?
Other good managers have also reigned in my ideas enough so that we implement what is attainable.
Bad project managers have had an obsession with statistics, spreadsheets and tools like Jira.
Most project managers I've had have been bad/indifferent, but with about 2 or 3 out of around 16 roles/projects being good/great.
One could imagine a PM saying to the team: "I go to meetings so you don't have to. But one of the tools I use to keep the finance people happy enough to keep this project fully staffed is those stupid metrics. Help me help you by filling them in."
It's really an awesome business model. Worked great for Microsoft. </rant>
Remember that your manager is accountable to someone else higher up the chain. They don't know how dev works, but they want to see quantifiable progress. Statistics, spreadsheets, and tools like Jira are how that progress gets communicated. Like it or not, this is an essential part of the business.
It's important to be on time. I've found that it's more important to solve the client's problem. And if you solve the client's problem well enough, the client will give you flexibility on the time.
1) Providing direct input, rather than summarized versions (even good project managers lose track of details and misstate things).
2) Learning what your project manager and others do. This can reveal corporate bullshit, but also enlighten you as to the amount of work that other middle-manager is actually involved with (and you may be surprised by their technical competence, or disappointed).
3) If you want to move out of a managed role in your company as a developer, and into a role that affords more authority and direction of projects (your own vision, if you will), this is a good opportunity to learn and to get face-time with people that you'll be interfacing with later, or that'll give you a promotion.
4) You don't find out secondhand what the corporate decisions are, you were there to witness them.
5) You learn what to say and what not to say to management. Never, ever, say that X is almost done when X is a prototype or subsystem. You speak about the completeness of the whole system, and then break down to the subcomponents. You learn the art of understating progress so that you don't seem to be behind (because you aren't, hopefully) but also to avoid the appearance of being further ahead (because it's just a prototype, or it's only one subsystem, or whatever).
I learned a lot at one of my jobs by being invited, as a lowly new-hire tester, to a few meetings with management. In particular, the smallness of scope of my portion of the project to the project as a whole, while still being on the critical path. Particularly, those meetings sat at the intersection of electrical, chemical, software, and mechanical engineering. That's where I learned what systems engineering was really about. A lot bad about that company, but outside their mismanagement of software, their understanding of systems management was actually pretty solid. That mismanagement was changing, but a lot of us software types didn't realize or understand our role in the whole process either (overvalued ourselves).
1) Communication on both a technical and product level. This allows you to act as a bridge between sales/marketing/management and the developers. See #2
2) Speaking two languages: Code and Product. This is where being a former developer comes in quite handy, as you can only learn Code through writing it, but you can implicitly pick up the Product by thinking like a non-techie and paying attention to what they care about.
3) Keeping a focus on the big picture during a project duration. As a Product/project Manager, you need to understand timelines beyond 3-6 months and make sure you're not shooting yourself in the foot for later. This is tangential to what you may have read in the Pragmatic Programmer.
4) Product/Project Manager can be squishy terms, meaning that the responsibilities can vary by company. Often you'll be left to ensure all the ends of a project are wrapper up: testing, documentation, communication on releases, etc.
There are probably many more things, but those are off the top of my head. Good luck!
Cheers!
The key aspects of project management are gating, communicating up, and communicating down.
Gating: Keeping things that aren't The Project from becoming The Project without being properly defined (time, deliverables, budget, resources).
Communicating Up: Letting business owners and stakeholders know the status and cadence of the project, what the project team needs to get the job done, what ambiguities need to be cleared up, etc. It's very difficult to hold someone's who is generally your boss feet to the fire, but it's am important skill to learn.
Communicating Down: Deliverables, roadblocks, obligations, morale, etc.
The most important skill in a project manager is humility. Many PMs see themselves as captains of some giant see-faring vessel, but have no respect for the vessel or the sea.
Just goading the team to go faster gives an air of testdriving ones new position unless there is some obvious, real, time pressure.
Rather - people often behave as they are expected to behave. Treat them as responsible, adult professionals, you get adult professionals. Treat them as galley slaves, you get galley slaves.
Mind you, all this is just introspection and armchair psychology.
I can read code and write it too, but mostly program simple front-end things or hack together side projects.
I'm good at telling people what they actually want from each other when they start arguing in a meeting. I'm the one who gets asked to write, simplify or clarify the concept of a new product. And as a generalist I will be asked about everything out of scope of the others (everything with media, much research, occasionally personal issues).
Regarding gating I have limited experience, but will be the one to try to get things out of the "MVP".
I'm currently in a very small startup and want to stick to it until after the initial launch of the product. Than it should become clear if things work out or not. I'm not sure though if I want to stay with the startup for further products to be launched.
I became an engineering manager at around 26, and did it for another 5 years, and thought that was my future. But I transitioned jobs and ended up getting back into development, and realized a few things:
- I hate meetings, and PMs go to meetings. A lot.
- PMs have less control then you probably think.
- Writing code means I get to actually make stuff. At the end of the day, as a manger, it was often hard to point to anything as a real accomplishment.
I'm 37 now, and have no desire to go back to being a manager. Now, maybe being a PM is what you really want to do, and if so, I wish you the best of luck. We could use some PMs with actual development skills.
Some people enjoy managing, unfortunately I just couldn't get into it.
I became a Project Manager right out of college after completing my CS degree and did it for ~8 years. I believe I was pretty good at it, but I don't think I ever once really enjoyed it. I spent all my free time coding, and eventually realized I probably should have been doing it as a job all along. I then spent about a year self-teaching, moved half-way around the world to San Francisco, and found a job that, more often than not, I actually enjoy going to every day.
I'm sure some people really enjoy Project Management, but each of the three points in the parent comments ring extremely true for me, so for now at least I'd much rather be coding!
You never feel a sense of accomplishment for making sure your developers are happily productive?
I'm a manager now and my team's high output and positive morale makes me extremely satisfied and proud.
For example, we work in an Agile environment, so I've started running some of the 'Agile ceremonies', such as story refinement, estimation etc. From there my plan is to try and fully manage a sub team for a smaller project, as mentioned above. On top of this, I've arranged to go on a Project Management course in a few months. Doing all this should put me in a good position for a PM/SDM role.
Hope this helps and good luck!
I'm a sysadmin and I've tried to simulate this kind of change and I found that there are a lot of bureaucracy tasks which I don't really like :). If you ask me, the proper career path has the "team lead" position as the first step, which brings you closer to a "* manager" feeling.
Good luck!!
Be ready is never ready.I just want to know what I'm missing and how to get it.
I don't see why there would be a specific list for programmers... but try and see if you can take on greater control of the tasks in your current job to build experience.
Before I ask this, I think I finger out what is Project manager & Product manager.I also take some note, after that I think the project manager is what I want.
MyNote: http://github.com/wenerme/wener/blob/master/tricks/devop/pm....
Some reference
What's the difference between a Project Manager and a Product Manager?: https://www.quora.com/Whats-the-difference-between-a-Project...
Product Management vs. Project Management: What’s the Difference?: https://www.productplan.com/product-management-versus-projec...
1. "Project Management for the Unofficial Project Manager" is a high-level but pretty complete introduction. It has good good examples from non-technical projects based on the Project Management Institute's infamous "Project Management Body of Knowledge" (PMBOK). https://amzn.com/194163110X
2. Scott Berkun's "Making Things Happen: Mastering Project Management (Theory in Practice)". Scott was a program manager at Microsoft and describes some of the less process-oriented, more "in the trenches" aspects to managing a project. https://amzn.com/0596517718
3. Steve McConnell's "Rapid Development: Taming Wild Software Schedules". It's more of an encyclopedia of software project management and is now a bit dated (1996), pre-dating Scrum and Agile but all those ideas have been known for a long time. https://amzn.com/1556159005
The second harder part is the mind set. Ultimately, you are responsible for the success or failure of the project. That means you need to do what ever it takes to make the project successful, and to be relentless in making this happen. Sometimes that will mean persuading business sponsors, sometimes it will mean chasing up why Developer Jane as the wrong version of the IDE installed on her laptop.
As Stuaxo has said, if you have a good team a large part of the job is removing obstacles for your developers. Another part of the job is attacking project risks and ambiguity around the project.
You also have to be prepared to frequently give bad or uncomfortable news to your senior management, and even tell them "No" sometimes.
I'd say learn what you can on the PM techniques, and then ask to shadow a good PM for the latter.
Experience is critical. Knowing what works is useful but more importantly knowing what doesn't work is essential. Focus on solving the issues and not on welcoming good news.
Start small. Do you have personal programming projects? Did you _project manage_ them? No? Then start by critically managing your own work. Stand back and introspect.
Do you want to manage any type of project or are you targeting technical projects, client projects, web projects? There will inevitably be a mixture so you need to understand that. Don't trust anyone. Keep asking for justifications and proof. Remind everyone about the different responsibilities that are present in any project and be specific about each individual's responsibilities.
What are you waiting for?!
Maybe I'm just not working for the right companies, but it really does look like the only way up is management.
Short chapters so you can read it in chunks, its entertaining and based on his experiences.
Included it in this list of start-up books I wrote ages ago but you've reminded me its worth re-reading - https://medium.com/@KatAlexPas/an-hour-and-a-half-a-day-of-r...
You may need to entertain taking a backwards or sideways step into a precursor role - local vernacular doubtless varies, but maybe explore Project Officer or Project Admin job titles. Or, of course, both.
You could start reading up on PMBOK, PRINCE2, Agile/Scrum, etc -- obtaining accreditation on these tends to be expensive and a little tedious if you're not actively using the methodologies (in my experience).
Or, do you mean programming manager? (i.e. less nitty gritty, more design, more delegation, presenting to higher ups)
For example:
- If you're going to do an API integration in the coming days/weeks, make sure you provide an account with access, documentation, and consider reading the docs yourself to look for blockers. Don't focus too much on the implementation or architecture, focus on the business goals.
- If you're going to make a modification or new addition as the result of a new business requirement, make sure you are intimately familiar with the business domain and how the problem applies. It's important for the PM to understand what the business actually wants, not simply what they say they want.
- Minimize task switching by maintaining a clear strategy with the business side. When you hand off a task to a programmer the task should be in such a prepared state that nothing further can be accomplished without writing code. If business has an "emergency" that isn't, urge them to hold off until the current development task is completed.
- Build relationships. You want to be close to business and close to dev. I would often talk to developers about their day, off-work activities, family events, etc. They were more than happy to discuss their hobbies for a few minutes, I feel like it's time much better spent than group meetings and it gives them reprieve from work. Get to know them, having that connection is great for them when they can openly make requests and likewise for you. Sometimes they need vacation on short notice. Sometimes you have legitimate emergency tasks and need to ask a little extra of them. Having a real relationship to fall back upon is tremendously helpful, just be sure to reciprocate.
As a PM you can advocate for engineers and protect them from waste like excessive meetings and ensure they have everything they need to do their job. You're in a position to suggest raises, hardware upgrades, etc. Sometimes you have to fight for what they need.
You can practice many of these things before being a PM. Some of them are better left for your first opportunity managing a project. Where that line is drawn depends on the specifics of your circumstances. I was promoted to management fast after making recommendations which dramatically increased revenue, which doesn't seem like a bad way to make yourself more visible. Solve business challenges or provide new revenue streams if you're extra ambitious. If you want to manage, show initiative.
It's also worth considering you might not be happy as a PM. No longer coding, it was easy for me to feel like I never got anything done. Entering tasks/todos/bugs, talking with the business side, and writing emails doesn't feel productive after programming. Being ready for that possible eventuality is my best advice.
As a PM, I usually refer to the stakeholders as the people that requested the project, the people that pay for the project, and the people that need to be informed about any changes related to schedule, scope, cost, impediments, etc.
>What's the difference? A Project Manager is rarely a stakeholder, though it could happen if the stakeholder is actually managing all aspects of the project.
It may benefit you to read the PMBOK and read some books on Agile and Scrum techniques. There are still many projects that use waterfall methodologies and are successfully on-time and on-budget. I was once a Portfolio Manager for a large insurance company in charge of data migrations from acquired insurers...there is nothing that stand-ups and scrum could have done to make the migration process any faster or better. Point: learn the basic methodologies first, then build on your knowledge. Agile and Scrum in the wrong hands can be terribly destructive. Knowing which methodologies may work best for different teams/projects/situations is key. Sometimes the overhead and bloat of Agile isn't necessary for simple projects. I once briefly worked as a subcontracted developer for a crappy consulting/recruiting company. The company wanted to "provide value" to the client by mandating that the client's IT Director and I had daily conference calls with the company's scrum master who only had 6 months of PM experience (I had 8 years of exp at the time). Which wouldn't have been unusual except I was the only developer, the IT Director wasn't involved other than "get it done" and gave two shits less about the daily stand-ups and agile process to design a 3-page site and a couple of forms, all of which had excellent requirements docs. I ripped through the work and got out of there in a week. Why apply such a ridiculous process/methodology to something so simple?
The other face of my role is being the intermediary between the stake holders and the team. While I am not a licensed engineer I try to behave as though I were: if I let bad code slide into production I might lose my license. The stake holders I collaborate with know this and they agree its an important position. However the business wouldn't move forward quickly if we were developing software like NASA. Instead I imagine there is an actuary assessing my technical decisions who will increase my insurance rates if I make poor decisions or lower them if I make good ones. This creates a risk-vs-reward balance that I need to consider when making decisions on behalf of the business... it might be worthwhile to accept some risk in choosing a software platform my imaginary actuary would asses as risky for the sake of the team who are familiar with it most. While I might enforce certain practices that will lower my rates like extensive fuzzing tests and formal specifications of critical components. It requires some balancing between correctness vs agility. While I don't see the two as mutually exclusive (in fact designing for correctness tends to make a team more agile in the long term) there is some give and take in terms of timelines and budgets that I need to be aware of. I act as the buffer between these concerns and the rest of the team whose focus should be on making software that fulfills our requirements and intentions. I attend the meetings and negotiate the timelines and handle the interactions with the rest of the business.
I think it's crucial for a manager of developers to have been a successful developer themselves with a wide range of experience. It's equally important to gain the trust of the team in your technical acumen: mandatory code reviews have been an invaluable tool in my experience so far. If you can give a good review it demonstrates your knowledge and wisdom while giving someone the opportunity to learn something new. It also lets you become familiar with everyone's skill level which is invaluable when trying to give estimates and quotes to stakeholders. Get out there and get some public credibility by contributing to open source projects, speaking at conferences, and even try your hand at writing. I've spoken at several conferences, have been a technical reviewer on a published book, and have contributed to the WebGL spec, Mozilla Firefox, Openstack, Python, and others. I'll be giving a talk at a local JS conference later this year. It will help if you can develop a reputation as someone trustworthy and wise.
Most of all... and this is universal; be aware of what you don't know. I've led teams in the past in the role of senior/principle/etc developer but I've always been sheltered from budgets, timelines, product scope, etc. I've been asked to interview people for positions but I've never been in charge of setting the policy on how we hire. I've learned how to adapt to social situations but leading people, especially creative and talented people, is like herding cats (I'm also quite introverted so it takes extra effort on my part to keep up). When you don't know how to deal with these things be honest and develop a plan of action to fill those gaps.
For me that means contacting people who I know are great managers (and not necessarily managers of technical teams either: one friend is a genius at running her fathers restaurant and her advice has been invaluable). It also means I keep a log of terms and advice I've been given that I don't understand. I use this log to do keyword searches and find books and blogs on the topics I'm missing out on.
Just keep at it and learn to look at the process of making software as one big software system itself. It can be quite entertaining and interesting.
Now, some people will try to tell you that project management is all about going to 3M with a forklift and getting multiple crates of stupid post-its. It's not. There's much more to it than just sticking post-its.
An engineering manager represents the ENGINEERING interests of a project, not only pushing features and saying "yes". Being a good manager is not about saying "yes", it's also about saying "no"... understanding tradeoffs and balancing them.
Saying yes to features all the time and discouraging quality will only create a culture of checked-out paycheck zombies.