As a Product Manager, Would You Shut Down an Engineering Project Started By a Technical Lead?

Let’s imagine you are a product manager who recently paired with a new engineering team. You come across a project initiated by a technical lead that you would rather shutdown than watch continue. What would you do in such a scenario? Even if you feel that shutting down the project is best for the company, there is a right way to go about the process.

Are You Sure the Project Needs to Go?

Before you decide you need to put the brakes on an ongoing engineering project, make sure you are on the right track. Some tell-tale signs of a project being in trouble include:

• The team has no detailed project plan.
• There is no clear hierarchy in the team.
• No one from the company’s senior management is backing the project.
• There has been no customer involvement in product definition.
• The customer has not provided any feedback on deliverables.
• There is no use of suitable project tracking tools.
• The team is overworked.
• Team members have ideas about how to provide simpler solutions.
• There has been little to no testing.
• There is no clarity on exactly what’s expected from the final product.

Shutting Down a Project

Every once in a while, there comes a time when a product manager needs to shut down a project started by a technical lead (TL). If you are worried this might reflect poorly on your own performance, don’t be. Here are measures you may follow to make the process go as smoothly as possible.

• Include the TL in your talks with other stakeholders, which include feedback calls. This gives you an opportunity to get a first-hand perspective. For all you know, the TL might also feel that the project needs to go.
• Determine how aligned the project is to your company’s goals, because shutting it down might be easy if it is down the priority list.
• If you can get the project into a beta or minimum viable version (MVY) state with little effort, you may track its adoption (or lack of).
• Begin user-involvement at an early stage, simulate possible results, get required feedback, and make your decision accordingly.
• Speak with stakeholders who wanted the project implemented and find out their reasons. Share with them why you feel moving forward might not be a good idea.

The Alternatives

While you might want to take a firm decision of shutting down a project, think hard in case other stakeholders do not provide their complete support. If you have been tasked with recovering an engineering project, start by looking for signs of over- engineering. In some cases, you might be able to pivot projects by adding capabilities that provide value to end-users. Pay close attention to numbers when justifying a product’s level of automation, be it the number of users or the time saved.

Conclusion

When caught in a dilemma about whether or not to shutdown a project that a technical lead holds close to the heart, determine what’s best for your company. Thinking about sunken costs will do no good, because there’s a good chance you will need to rebuild anyways. Cutting your losses short - and even starting over if you have to - might be in your best interest.

If you think somebody in your team is always the “idiot” you are the jerk.

Do you think there is someone in your team who is a perpetual idiot? Are you of the opinion that you are way better than the person in question? If so, you might be the one who others in the team look upon as a jerk. Fortunately, identifying the problem (with you) and following a few simple remedial measures should hold you in good stead.

Why You Are the Jerk

Failing to appreciate others’ perspectives, having an air of superiority, treating supposed idiots as tools you can manipulate, or thinking of them as people you need to deal with instead of your peers, makes you, well, quite a jerk. This is because you fail not just at the emotional level but also intellectually. Consequently, it is you who is left wanting in these aspects. 

Signs of You Being a Jerk

The typical workplace jerk thinks of himself or herself as more important than his or her peers, and tries to exercise undue control on subordinates. Such employees tend to lend importance to the opinions and perspectives of those who are higher up the hierarchy ladder. If you feel someone is your team is always being an idiot, here are some other signs that you might want to watch out for and avoid:

• You are pushy and/or intrusive
• You are mean and/or disrespectful
• You refuse to look at his/her accomplishments
• You are not appreciative

If you find yourself whining or complaining about one or more employees, bear in mind that it never helps – and this applies in your personal life as well.

Signs That Your Peers Think You Are a jerk

If you keep looking down on anyone in your team, your coworkers probably already view you in bad light. Here are signs that might indicate it is happening.

• Your team members argue with you frequently
• They avoid you when possible
• The do not help you, and do not ask for your help
• You feel they are sarcastic and/or rude
• Their body language is negative
• They laugh at you, or snicker even when you are not trying to be funny
• Your success comes as a surprise to them

What You Need to Do

For starters, get rid of all the airs you have about yourself. Then, understand that the coworker you think of as an idiot might be inconsistently motivated or may simply not have the same priorities as you. In addition, some employees don’t go that extra mile in the absence of effective communication or recognition. Even if you are not in a position to bestow rewards, you can still highlight how the individual’s work is important to you, the team, and the organization. Just like you want your work to be acknowledged and appreciated, so do all others.

Conclusion

Viewing someone in your team as an idiot comes with no benefit. If anything, you might take on the role of being everyone’s fool yourself. If find yourself thinking you are better than someone at everything, it is time to take a step back and recalibrate your thoughts. Not only will the other person have positives you can look up to, identifying and working on your own flaws will help as well.

If you have any questions about this post, please ask by using the comments section. If you found the content to be helpful, please hit the like button and share it with others. To read more content related to careers in software, follow us now.

What is an SRE?

Introduction

With the incorporation of software in almost every industry and the huge dependency on programming and computer science, it was just a matter of time before a new discipline was introduced. According to Ben Treynor Sloss, who is Google’s engineering vice president, “A site reliability engineer is a software engineer who is responsible for developing an operations function”. Site reliability engineering (SRE) uses the versatility of software to handle regular IT operations such as server management and other computer operations by establishing reliable software systems. SRE task forces usually utilize and develop software to handle project issues and problems, increase project autonomy and manage the entire project’s process with minimum manual intervention and manpower. Despite being a commonly used term in classifying work teams, the majority of the people working in both software and project management industries are still not fully aware of the underlying concept behind site reliability engineering. This article is an attempt to clarify what does an SRE do, how is an SRE important to business and projects, how are SRE teams different from DevOps and what kind of tools and technologies that an SRE utilize.

What does a site reliability engineer do?

SRE work can be divided into two main tasks. About half the time is spent on developing and programming new features, increasing system autonomy and project scaling. The rest of the time is spent on operations related work including tasks that require personal intervention and on-call duties. So an SRE should have a balanced mix of system administration skills and software programming, automation and engineering. Among the duties of an SRE is the code deployment, configuration and monitoring in addition to responding to emergencies and managing production service capacities.

How important are site reliability engineers?

SRE makes the project management process of large projects easier by developing complicated codes and algorithms that handle most of the regular and daily tasks. The software developed can be expanded to administer a huge spectrum of machinery and equipment within a company. As I mentioned earlier, SRE’s work can be divided into two main sections, standardization and automation. It is the goal of an SRE to improve a system’s reliability and features while automating operations tasks. The unique role of an SRE requires programming skills and operations management experience. SRE teams are particularly important for startups. Due to its small scale and inability to hire large groups of developers at large scale, having SRE teams would be extremely beneficial for the startup. After understanding how important are SRE teams to a company and what kind of work do they handle, we now need to discuss how do SRE teams work within a development team. 

How different are DevOps from site reliability engineers?

Site reliability engineering implements the idea of DevOps at its core. But what are DevOps? DevOps simply denotes development and operations, where developers are responsible for writing codes, which are then passed on to the operations team for installation and support. However, due to the separation between both teams, developers were not responsible for how the software or features would be used, leaving the operations team in a bad position. This led to problems because the goal of the developers is to keep introducing new features for the customers with new pieces of code, whereas the operations teams are seeking a steady system with stable and steady changes. However, by combining both teams and helping them understand each other’s duties and responsibilities, introducing new features will not only be based on developing the code for the feature itself but also on the consequences and fallout this new introduction might lead to. DevOps and site reliability engineering are often confused because of their similarity in many aspects and properties. Both DevOps and SRE seek high quality and fast services delivery as well as life cycle development, by optimizing business value and responsiveness through automation, platform operation enhancement and integrating both development and operations teams. Now, let us see how is SRE different from DevOps. First of all, SRE teams take to their own hands the duty to eliminate communication and workflow issues. SRE teams’ main goal is to achieve site reliability while adding novel ideas and features, whereas DevOps are mainly concerned with efficient development of operation using platforms such as Kubernetes and microservices. Unlike DevOps, SRE teams split their working time between operations and development tasks such as systems scaling and automation implementation, which is a crucial aspect in the site reliability engineer’s role. A key component for SRE teams is to achieve that balance between both operations and development work. 

What kind of technology supports a site reliability engineer?

In order to determine the type and time of features to be launched, SRE teams use Service Level Agreements (SLAs), which are used to determine the necessary system reliability depending on Service Level Indicators (SLIs) such as availabilities, rate of error, requested latency and systems throughput, and Service Level Objectives (SLOs), which are based on specified goal values and budget error. Due to the fact that an integral aspect of SRE’s work is automation, unified software containers usually provide teams with a common development environment facilitating work integration, automation and delivery.

Conclusion

Incorporating site reliability engineers can be handful especially for startups. They can assist developers by solving some of their general issues, hence providing them with more time to handle programming specific issues. They can also improve the capabilities of the tools used by developers to help them become more productive. In addition, the customer will be provided with a product that has high reliability and security. It is important to mention that finding an SRE to join the team is not quite simple due to the fact that they are looking for a person who are able to multitask and handle both operations and software engineering at a high level. It is always a pleasure to answer all your questions and see you in the next one.

**Note: All the attached photos are royalty free and not copyrighted. 

Facebook – Solution Engineer vs Software Engineer

**Note: All the attached photos are royalty free and not copyrighted.

Introduction

As we all know, Facebook is one of the largest tech companies in the world in the meantime. It ranks in the fifth place according to brand value compared to other tech companies in 2020 with a whopping 147 Billion Dollars. Facebook Inc. has also acquired multiple tech companies in the last decade such as WhatsApp, Instagram and more. Without a doubt, it is mesmerizing to be part of Facebook, whether as a software engineer, a solution engineer, or at any other position. However, if it is an option that you can choose between a software engineer and a solution engineer, then there are some points that you will have to consider before taking the decision. In this article, I am going to point out the major differences between both roles, and hopefully help you pick the one that is more suitable for your preferences. 

What does a Software Engineer do?

A Software Engineer utilizes his/her knowledge and expertise about computer science to write codes using programming languages, in addition to servers, databases and frameworks that are used to create computer or mobile applications, operating systems … etc.

The software engineer’s responsibilities can vary from one job to another and there are many career paths for a software engineer other than coding jobs. Here are some examples: web developer, mobile developer, test & quality assurance engineer, machine learning engineer, data scientist/engineer and much more. 

What does a Solution Engineer do?

A Solution Engineer is like a job description and not a field of engineering. It also requires a bachelor in software engineering or computer science just like the software engineer. Nonetheless, a Solution Engineering role can be considered the interface between the development team and the client or the customer. The solution engineer also makes use of computer science principles to make sure that every component of the product or the software is running seamlessly as it should be, without any glitches or lags. The solution engineer is not only responsible for the software part of the product; however, he/she is responsible for the integration with the hardware components of the system. Not to forget that another major role of the software engineer is to familiarize the client with the product; that includes operating demo presentations and some technical meetings explaining the product or the system. 

Major differences between both roles

One of the qualifications that should be found in the solution engineering role and not in the software engineer is the fair knowledge of sales. The solution engineer is the one responsible for outlining the client’s needs and delivering it to the development team making sure that the client is satisfied with the outcome solution. As mentioned earlier, the solution engineer is more of a client-facing role while the software engineer is more of a back of house role that is not felt by the customers. 

Responsibilities of a Software Engineer at Facebook

Just similar to any software engineer, they are working on creating new products and systems that run the Facebook Group’s apps and services. The software engineering force at Facebook is divided into multiple teams, which are Products and Services Teams, Infrastructure Teams and the team of Specialists. The first team is focused on utilizing new technologies to create new features and improving the existing ones. The second team works on ensuring the stability and efficiency of the infrastructure of Facebook such as servers, data storage, system resources and more. The final team, which is the team of specialists, usually work on integrating the new technologies with the complete structure of Facebook. 

Responsibilities of a Solution Engineer at Facebook

A solution engineer at Facebook, his/her time is divided 50/50 between two main sorts of tasks. The first one is to code and develop new products and services just like other software engineers. The other sort of tasks is actually a combination of activities such as dealing with support requests, performing adoption of new products to be able to comply with Facebook’s technologies, interacting with clients and partners, doing public speaking or even writing some blogs. 

Conclusion

Assuming that you have the opportunity to choose between the two positions, your choice should be based on multiple factors. The most important one is to choose the role you are more passionate about. You will perform better if you’re enjoying what you are doing. The second factor is the career future. As discussed earlier, the major difference between a software engineer and a solution engineer is how deep you are involved with coding. Software engineers purely write codes, on the other hand, solution engineers are more client facing with some sort of involvement in code writing. It is totally up to you to choose the track you want to take. Specifically, at Facebook, code writing is highly integrated in the tasks of a solution engineer. Accordingly, you will not miss the benefit of being into coding on a regular basis with the addition of gaining experience from clients’ interaction and sales tasks. The third factor is the salary; both roles are paid roughly close figures. The average annual salary of a software engineer is around $92,000. For the solution engineer, the average annual salary is around $100,000. The common qualification that you must have to work at Facebook is to have brilliant developing skills; hundreds of millions or even a billion users are testing your output every month so any mistake will be very costly. 

References:

https://www.reddit.com/r/cscareerquestions/comments/bmer6i/solutions_engineer_vs_software_engineer/

https://www.quora.com/Is-it-better-to-be-a-solutions-engineer-or-a-software-engineer-With-respect-to-future-growth-and-salary

https://www.quora.com/Is-solutions-engineering-at-Facebook-a-fancy-term-for-tech-support

https://www.quora.com/What-does-a-solution-engineer-do

https://codingnomads.co/blog/what-does-a-software-engineer-do/

https://www.glassdoor.com/Job-Descriptions/Solutions-Engineer.htm

https://www.facebook.com/careers/areas-of-work/engineering/?p[teams][0]=Software%20Engineering&teams[0]=Software%20Engineering

https://www.facebook.com/careers/life/solutions-engineering-at-facebook