An SRE team deals with various domains of influence. I am outlining some of the ones that I find to be the most prelevant, in no particular order.
Sometimes an SRE organization may be known as the ‘no’ organization. This is really unfortunate. I would like to say that an SRE team is a ‘yes, if…’ organization. What I mean by that is, yes, you can push to production, if you have not exceeded your error budget.
SRE teams deal with a large cross section of infrastructure, such as analytics, notifications, validation, logging, monitoring, provisioning, storage and compute. Across all these functions, SRE’s have to be mindful of reliability, availability, scalability, automation, isolation, capacity planning and cost.
Working in technology, I have had to deal with my fair share of prima donna engineers. A few characteristic that such engineers share include high technical skill set, low social skills, egotistical, argumentative, arrogant, stubborn, impatent, and overall difficult to work with. Some companies tolerate prima donna engineers because they are willing to overlook the other negative aspects due to their technical contributions. I outline some ways of dealing with prima donna’s here.
One technique is to try to overlook the negative aspects of the prima donna engineer, focus on the value he/she is providing. Another technique is to give the engineer a project that does not require much interaction with others. Alternatively, you can try to find projects where their impact is significant enough their negativity stays at a minimum. Give honest feedback to them, and let them know how their behavior impacts other team members. Lastly, if none of this work, then let them know that their negativity will not be tolerated and they will have to find another place to work.
I had a manager once who would say his hiring strategy is ‘no a**holes’. He was of the opinion that just like a fruit bearing tree which bows down because of the weight of it’s fruit that others may enjoy, a knowledgeable person will be humble to benefit others.
Prima donna’s will require a lot of supervision and monitoring from you as a manager to avoid a negative impact on the team, before you hire them ask yourself if they are worth the trouble.
If you are wondering what are some of the characteristics of micro-services, I hope you find the brief blog useful.
Microservices are decentralized by nature. A single unifying schema or data model is not required from them. They also do not have to reside close to each other geographically.
Microservices are independent of each other. They can be deployed, upgraded, maintained by independent teams and also on independent compute and storage. For instance one team may be responsible for front end and another may be responsible for backend.
Microservices are polygot in nature, they don’t follow “one size fits all” approach. They take independent approaches to programming tools, and also programming languages. For instance, one team may choose Java, and another team may choose Golang for programming.
Microservices are good at doing “one thing” well. They don’t have to do more than one thing. For instance, in case of a social network online application, a microservice may be responsible for just authentication, and nothing else.
Microservices are independently managed. They can be upgraded or changed independent of each other.
Microservices are ‘black boxes’, in the sense that they hide the implementation complexity from each other. Using a previously agreed communication method, such as REST API, they can avoid knowing details about how each other work.
Some of this material is credited to AWS whitepaper on microservices that can be found here.
When you hit a roadblock in a project what do you do? The correct answer is not “panic!”. The correct answer is “keep calm and carry on”. I have highlighted some steps that you can take to mitigate the impact of a roadblock.
As much as I would like to take credit for the above methodology, I cannot. Credit goes to ‘Ali Mehdi‘ for describing the steps.
When building a new team, a number of factors have to be taken into account. These can be summarized in a visual called a ‘team canvas’ , as seen below.
Why was the team formed? Define the purpose of the team in the center. List some of the values you want this team to have. Next, define the people and the roles that will make up this team. Follow that with some common goals that the team comes up with.
Ask the team to write their strenghts and areas of improvements. The team will need some tools to get their job done, list those under ‘needs and expectations’. Set some boundaries with rules and activities. For personal growth figure out what each team members wants to accomplish and list those in ‘personal goals’ section.
Creating a team canvas will help create structure for the team. It will give others an overview of the team, and it will also help in keeping the team headed in the right direction.