I am a team lead in an outsourcing company. That means I believe (or convince myself) that I lead the team (wait, wait, there will be even more obvious discoveries).
I am sure that a team can achieve more than a single person or a group. And the story I want to tell is about making the team from a group of people with personal and non-connected tasks. I assume this is going to be a series of posts, and hopefully, I will add a table of contents here.
A group or a team?
It is quite rare to find a project that involves more than 10-15 people in a small or mid-size outsourcing company. With such project size, a single DevOps engineer is enough to handle the whole job. Or an engineer may work on several projects at the same time if projects are relatively small. This is because the scope of work to be done fits into the schedule of a single person. So it is either one-to-one or one-to-many connection in most cases: either the employee works with one project or the employee works with several projects simultaneously.
Outsourcing a “DevOps” within this context usually means assigning an individual for the work with a client or/and a client’s team.
Now imagine: you have several people in a room, all of them are DevOps engineers working in the same outsource company and all they work with their “own” projects separately.
So would you call that group of people “a team”?
Wikipedia states that “a team” is a group of individuals (human or non-human) working together to achieve their [common] goal. As well as common sense tells us that “a team” is something that groups people to make them work for a mutual outcome.
And here comes an obvious but a difficult question: what common goal(s) a group of people can have whereas each member of that group has its own goal, which is not related to others’? A bit contradictory, isn’t it?
Conventional thinking tells us that a goal for the for-profit company is to make money. This is true, and I don’t want to argue with it. Therefore, does it mean that a goal for a team of engineers inside the company is the same as for the company as a whole?
Yes… Yet, not only, or almost.
Yes, because it’s the main reason why we work for an outsourcing company. We do the job for clients, clients pay the company, the company pays us.
However, there is a long chain of events and processes that leads from the start of a contract to the paid invoice. A team of engineers is the inalienable part of that chain, with a focus on its work - deliver technical solutions following the client’s expectations and requirements.
This conclusion reveals the goal for the DevOps team in the outsourcing company: grow the quality of work by a process of ongoing improvement and refinement of technical and soft skills. So simple, so obvious.
And this goal means nothing by itself. But to sustain it and adapt, to make it desirable for the team, and to make it a team’s foundation eventually, we need the following:
- Common interests
One of the crucial responsibilities of a team lead is to foster these three pillars of a team.
The VALUES is something that lets us feel comfortable with the people surrounding us in the office. The list of values is not carved in stone, it can (and eventually should) change as the team evolves. But here is the most constant items for my team:
- openness in communication
- respect to each other’s opinion
- feeling free to provide critic and being ready to receive it
- count on help from a teammate and be ready to help
- ability to work remotely and have flexible working hours
The PRINCIPLES is a set of beliefs and policies that keeps us on the required level of productivity and disciplines us, and stimulates the longing to improve. Again, this list can be and should be adjusted as the time goes and the team evolves, but here is the most up to date for us:
- we learn constantly
- we are the first who appraises the quality of our work
- we are proactive
- we are open: if we do not agree with something or something is worrying us, we should be brave enough to say it
- we may defend own point of view, but be ready to accept that it is incorrect
- we can make mistakes, but we must learn from it and do not repeat them
- we must help our teammates
- we keep our promises
The COMMON INTERESTS is more about informal things we share within a team. This includes (but not limited to) team building events, discussions and arguments about new technologies, so-called water-cooler chats, and so on. Being less formal, this pillar acts as a glue for the team. This is because we are all humans, first of all, and we generally work for 1/3 of our day (not including weekends), so we need to stay humans at work as well. I mean it is impossible to switch off the ‘human’ for that 1/3 of the day, leaving only the engineer for this time. Hence, this must be admitted and we must cope with it by putting several informal things into formal work.
These pillars create a team culture where learning, creativity, and an open mindset are encouraged.
This is how a group of people with separate goals may become a team. While we do not have a goal (“one for all”) that is measurable or has a fixed point of completion, we still have a common aim whose realization is based on pillars of teamwork. And with a set of sub-goals, this may be a specific, achievable (until you find something else to improve, which should happen quite often) and even realistic. So it’s kinda 60% S.M.A.R.T. goal
Unfortunately or fortunately (if you like your team lead job) there is a lot of work that needs to be done and a lot of questions need to be answered to implement the described approach:
- How to translate own values to the team and create the new ones together?
- How to make people communicate in such a team and share their knowledge?
- How to define who does what?
- How to teach team members to learn?
- How to keep team members loyal to the team and company?
- How to mitigate conflicts and how to use them?
- How to keep team members motivated when the work becomes boring and the level of engagement goes down?
- and much much more
I wish I could answer all these questions at once, and I wish there were only correct answers. But my experience tells me that it is possible to answer them one by one. And I hope to share that here someday!