The best project managers I've had have identified and removed obstacles for me (including things like - attending mandatory meetings, so the devs don't have to).
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.
Agree with not going overboard with stats and Jira. However being good with these tools to help measure velocity and improve the quality of estimates reduces the pressure on the team when clients plant the seeds of doubt that you've over estimated.
I agree it's possible to go overboard, but I find that a lot of developers don't appreciate how useful it is to have documentation of what the team is doing and visibility (ie numbers) into how time is being spent. A lot of developers hate tracking task in jira or any task tracker, but whenever deadlines start being missed due to roadblocks thrown up by other teams, or ineffective project management, having that all documented can really help resolve toxic situations.
Then one of the requirements on the project manager would be to communicate what his own constraints and objectives are to the team, right?
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."
<rant>
I don't know, Jira feels like a conspiracy theory in action: Atlassian somehow tricked management into adopting JIRA. Then the management had to pay insane prices for external plugins in order to allow programmers to do trivial things like displaying in a visually appealing way hours spent over a week.
It's really an awesome business model. Worked great for Microsoft.
</rant>
Attending some of those meetings, as a developer, isn't all bad, though. It can be useful for:
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).
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.
Yes, it is important. However, some project managers obsess over it. Instead of focusing on delivering something the client wants and finds valuable they obsess over estimates, minimizing change orders, and time spent, to the point where it becomes the single determining factor in what we do and don't do.
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.
The best measure of how a project is going is using the software it is producing. Instead of using questionable data from Jira and the like, just try to use the software. Ask for a demo, or run the code yourself, or look through unit and acceptance tests.
Direct supervisors can do that and get a detailed feel for how it's going. But that's too touchy feely, too many variables. C-level execs want to know "are we on track to ship version 3.0 by the end of the quarter?" and they need a yes/no answer, justified by numbers and graphs. They don't know about unit tests, and can't be bothered to walk through the software itself.
Speaking of the tools (spreadsheets, Jira, standups, etc), the tools are there to help you execute your process, they are not your process. Too often I see people try to fix their process - or simply the lack of a process - by throwing random tools or catch phrases at it.
I've recently gone from Developer to Technical Product Manager, and I believe the following traits are important:
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!
What motivated your transition from Dev to Product manager? I am looking to make a similar switch, would it be okay to reach out to you for guidance? Advice on the transition would be incredibly useful!
99% of the time "Project Manager" means "Project Facilitator."
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.
To add one more: a sense of urgency. Your job isn't to whip the team, but you should provide a steady drumbeat of progress, and be able to instill urgency and speed into the team.
"you should provide a steady drumbeat of progress, and be able to instill urgency and speed into the team."
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.
This sounds like it suits me very well. Any advice on how to get there without being a very good programmer?
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.
You don't have to transition. Think hard before you do.
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.
I'd also echo the suggestion to think hard about whether you really want to be a Project Manager or are you just following what you think is a traditional 'career path'.
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!
I see that as the point of GP's comment: different people get satisfaction from different things, and different people excel at different things. That's normal.
This is almost exactly the same for me. Except I was 28 when I became a "Development Manager". It quickly became clear that I felt I wasn't accomplishing anything, and the times when I was able to actually code felt completely liberating.
Some people enjoy managing, unfortunately I just couldn't get into it.
I'm in a similar position at the moment. Basically what you want to do is ask for more responsibility from your PM, specifically to do work they'd normally do. Over time, that work will become part of your responsibilities. As you gain more confidence from doing those tasks, and as your team begins to recognize you moving away from programming and taking on more leadership, you'll put yourself in a good position to manage a sub-team on a small project. If you can pull that off, you can build on that for a bigger project/promotion to PM/SDM.
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.
Thanks, I think you are the lucky one. Our company got ~100 emp, but IT dept only got 2 backend(includ me), 1 frontend, 1 android, 2 ios.There is no one I can learn from,so,there is no real world practice or example.This is very common in China, just get things done, we got people.
Ah ok, sorry to hear that. With such a small development team, it sounds like it could be hard to move into management. However, this should also present opportunities: if you see something that needs to be done and no one's dealing with it, do it yourself, accept the responsibility and try and make sure some one notices that you've gone to that effort (or ideally, point out the fact that you're going to do this to whoever you report to).
You will have to pick up some general management skills and for that I can not recommend enough The Mobile MBA by Jo Owen. Thin book, no BS, no fillers, practical and useful advices from a successful manager. That book should have been named MBA 101 for programmers.
I think it would be a great exercise to shadow your Project Manager(if you have one) for a while. If you don't have one, maybe just try to virtually manage the project you're working on. You'll find that the PM job is not really what you expected to be.
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.
I can feel that at work, but the PM skill is required to improve myself, maybe I don't need that skill in my work, I got some extra project out of work, I hope I can manage that well, then we may build a studio or something.
Be ready is never ready.I just want to know what I'm missing and how to get it.
Decide if you really mean Project manager, Product manager or Programme manager.
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.
Also, ensure it's one of the above and not an Engineering Manager. The expectations are quite different for each roles. I have been burnt by my mistakes when I tried to do everything whilst being a Technical Lead of a project. It burnt me out, but taught a valuable lesson.
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.
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
There are two aspects to project management. The first aspect is being able to manage the methodologies and techniques popular at your employer EG managing a sprint, building a gantt chart, creating the necessary project artifacts etc.
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.
If only life were so easy then a roadmap or checklist would solve everything.
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.
My only advice is to not simply jump into a management role because it is the only career path you see. You can still be technical and progress your career! I definitely encourage you to try and experiment different roles, though, as this brings you versatility and understanding the lifecycle of a project.
How does one get one of these non-management yet senior jobs? Companies like to talk about a "technical track" but I have yet to see anyone climb up it. I've seen senior engineers hired from outside into fellow type roles. But those seem to degenerate into management roles anyway.
Maybe I'm just not working for the right companies, but it really does look like the only way up is management.
It's tricky. As with any career (or just job-title) change you can try to manipulate your current / next role into including the key responsibilities of the new job title you're after -- in this case a PM -- and then try to leverage that work experience into a formal PM role.
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).
Thanks, english is not my native language, as a normal family in China the ability to read or write english is learned by myself, I will read and learn what your suggest.
See if there are any certifications your organization prefers. My work values people with PMP certifictations, or at the very least a Masters Certificate in Project Management (which they offer on site).
Understanding the types of things that prevent programmers from completing their duties is the core of PM. That can be resources/access, requirements understanding, scheduling, productivity, etc. It's most helpful if you can achieve a deep understanding of the business objectives while understanding technical capabilities and limitations. Most programmers are required to do that anyhow, but it's especially important in PM because you'll be one of the earliest people on the tech side to influence new projects.
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.
>According to the Project Management Institute (PMI), the term project stakeholder refers to, ‘an individual, group, or organization, who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project’ (Project Management Institute, 2013).
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?
I'm in the process of making this transition. One of the most important things I'm trying to hold on to is a passion for programming that goes beyond writing code. I see my new role as leveraging the 13+ years of professional development I've invested in by providing my team with guidance and critical feedback while ensuring business takes on less risk by making sure the software my team produces follows industry state-of-the-art practices and meets our deadlines. I tend to look at software development as an ongoing process and I hack the process itself to get the results I want rather than relying on my own immediate intuitions and knowledge about programming. In essence I set up the guidelines and processes that let my team be the best developers they can be and help them any way I can.
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.
i recommend poisoning the current project manager and offering to step in. when you are a manager you cannot afford the luxury of a consciousness so this is a great way to start!
Please take a look at the IEEE's Software Engineering body of knowledge. It will give you an outline of the topic as well as pointers to what reference material you can consult.
I strongly encourage you to take a look at this book.
It is a tour around software engineering including budgeting, planning, implementation, releasing... everything that you can think of. Always useful to take a look at it to find out where the gaps or weaknesses are in your knowledge.
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.
Project managers and programmers are blood rivals. So firstly, never seek appreciation from your team. If you get some, always be skeptical of these possible sycophants. Secondly, never try to be their buddy - it will never work, and if it seems to, it just means that they are tolerating you. Thirdly, you should use the phrase "good job xyz" ad nauseum (Programmers know that it is BS most of the time but still expect it most of the time). Lastly, learn Excel, especially merging cells and bordering and coloring them..
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.