Working with the engineers
Software Engineer Hiring and Interaction - India and Philippines
Who is a software engineer? The basic and standard definition is that a software engineer is a person who applies the principles of software engineering to the design, development, maintenance, testing, and evaluation of the software and systems that make computers or anything containing software work.
Who is a product manager? The basic and standard definition is that a product manager communicates product vision from the highest levels of executive leadership to development and implementation teams. The product manager is often called the product "CEO." The product manager investigates, selects, and drives the development of products for an organization, performing the activities of product management.
Now, according to Julia Zhou, who has worked as an engineer and a product manager throughout her career, software engineers need to be given the deserved credit for their work and innovative behavior. It is they that make an idea or a mock come to life.
She also suggests you find a good UI orientated engineer if possible, though they are in high demand. If not, try to get the software engineer to appreciate the design by explaining what you are doing and why you think the design should be build. This will avoid having disputes initiated by the software engineers themselves concerning the feasibility of the project.
Moreover, the more excited the software engineer is about a project, the faster they will design it and implement it.
Also, help a software engineer understand when their design matches the mock, if not, try to convey why it doesn’t. Sharing your thoughts on a failed prototype will help them understand what you do not want to see in future again.
She suggests product managers take out time out of their regular schedule to get to know the engineers outside the working environment; this will help build a stronger working relationship.
Furthermore, as a product manager, avoid being set for conflicts with the software engineer in process by understanding the constraints early on.
This means when in future you will have a great mock idea, but don’t feel quite sure about it; ask the software engineers opinion on it. Vice-versa holds as well.
Save the software engineers’ time; help them understand how final the design is at any given stage.
Also, avoid conflicts where changes are involved. Avoid this by letting the engineer know that the design might be changed at any time. This way you will avoid nuisance for the engineers, and their complaints that could turn everyone on the team against you, as a product manager.
Think about setting context on what pieces are still exploratory and what pieces are locked down helps engineers figure out how to design a code that is either quicker to write or more easier to modify later on in the future.
Moreover, consider getting everyone on the team to sit down together when the implementation process will take place. This way if any problems surface, it will much easier to solve once everyone is present.
It’s common to blame the software engineer when the end product is not what everyone expected it to be. That’s disastrous thinking right there. Hence, as a product manager, forget it once and for all.
Follow some simple steps such as:
1. Make sure your designs are complete. Don’t just design for some for the sake of designing it. Get out of that routine .As every software engineer knows, what counts at the end of the day is what ships.
2. Get the engineers to understand that the product managers’ job is to be a connector that helps the team ship successful products at the end of the day
3. Be a clear communicator: you need to represent the goals, priorities, and roadmap of a team to many constituents, including legal, marketing, customer operations, sales, and more. This means they need to be crystal clear, succinct, and on-topic.
4. Be organized: in order to successfully ship great products, a product manager must have a clear understanding at all times where the project is going, and if it’s on time or having delays. This requires high level of organizing skills.
5. Be able to execute: In other words, executing means making sure that everyone knows what is expected of them, and do it, most importantly. As well as, estimate the time needed, to complete the project and meet the deadlines.
6. Be design orientated: This means that one should appreciate, and understand what design has the potential and what design does not. This does not necessarily mean that the product manager should be a good designer himself. He should, also, value the engineers input even if it isn’t exactly what was required to be done.
7. Have analytical ability: This means how well a product manager evaluates known inputs, such as quantative data, tasks, user feedback, past experiences, when putting together a rationed plan for the near future. One should aim to consider known and unknown circumstances, as well predict their future possible changes.
8. Have product vision: This means having the ability to read the market trends and their changes, market problems, competition, and social attitude towards new software programs and platforms. Product managers who have this skill tend to install confidence in their teams, and inspire software engineers. Especially young ones.
As a product manager working with a software engineer, it’s important to keep in mind that the overall team must be well-balanced and well-suited to the project and the design at hand. This means, for example, product managers who are weaker on design thinking and the projects feasibility should probably difficult projects like redesigns or some major new user product, or be paired with senior software engineer who can help fill that skill gap. Similarly, software engineers who need more structure around goals and timelines may do well to have a strong executor product manager to keep them focused on the most important things.
Your job, as a software engineer will be much easier if you treat your product manager as a partner and a resource, not as manager or head of the team.
Some software engineers do not understand the need to have product managers on the team, viewing them simply as managers and irrelevant to the overall success of the project. However, those software engineers need to consider the following;
1. If context is required on certain related product field, a product manager will have that covered. And if they do not, they will introduce you to someone that does.
2. Feedback is of most essentiality to software engineers, like said above; it lets them understand how close they are at any given time to the final product. Product managers are go to people for feedback.
Unfortunately, no disagreements can be avoided. This is definitely going to happen. On most occasions it is totally okay. Most of the time it’s okay, it’s just the usual system of progress between three aspects of product development (product, design, and engineering).
There are, however, few common ways these disagreements usually occur.
One of them is the dispute on whether the final product is ready to be launched. Because product managers are responsible for meeting deadlines and making sure the product is launched as soon as possible, they do tend to be quiet aggressive in pushing forward the software engineers. It is known to all that software engineers tend to be more worried about the customer experience, and can sometimes prolong too long in their attempt to perfect the product. This prolonging can take place at any stage, from design, implementation and polish stage.
This scenario is a double edge sword, because no one on the team would want to launch something tomorrow that is not ready to be launched. This being said, nobody wants to design something for many years either. This lays perfect foundation for many disputes and conflicts on the team, primarily between the product manager and the software engineers. What can a software engineer do to avoid these conflicts? Lay out your position to the product manager calmly and in a rational manner. Going through pros and cons of what the team stands to lose or gain by either going through with the early launch or delaying it. You can also do an analysis of what you stand to lose or gain by delaying the launch.
In addition, keep in mind that the quickest way to a product manager’s heart is to be reliable.
Avoid disappearing after lunch on Sunday until Thursday morning to find your so called ‘creative you’.
As a software engineer, you might not know exactly when you can come up with something that will be great and practical. And, might even surprise your product manager and the whole team. However, try to always let your product manager know what you are doing, when you think you will complete a task, and what you think should be done more.
Let the product manager know difficulties of in-progress work and your constraints within the team. Explain why you’re still trying different things, and the reasons you’re not content with what you have done already. The fact that you share all of these with your product manager gives you instant reliability credit.
Avoid at all cost to live up to the common conception that software engineers are too arrogant, messy, and sometimes plain rude.
Try not to say ‘no’ before you have heard the whole story behind the proposed design or project.
Also, keep in mind that a product manager does not have to be technical by all means. Neither with you, as a software engineer, nor with the customer.
Lastly, remember that, as one great product manager said, you are more than your code.
So next time you take up a project, make sure that you’re not a short-order cook.
Avoid accepting a job where you will be told exactly what to build and how to build it. You need to work in an environment that appreciates your insights into the product as well as your ability to build it.