Digital Transformation Journey

In today’s information world, of all the people use internet, about 10% of the people are content producers. They produce most of the content and the rest of the people are consumers. It is probably a rough estimation. But let it be writings or videos, it is true. Only a small percentage of people produce these and post to different sites or apps. Knowledge sharing at work place is also very similar.

Let alone job responsibilities or not, a small percentage of people by nature like to produce content and share with others. Even though everyone at work are encouraged to document and share knowledge, most of people are just like consumers. But this is fine. Work place should provide platforms to make it easy for these content producers to create knowledge sharing content and share, such as slack topic channels, company wiki site, or the readme file for a repo, etc.

How about the people that hold certain in depth knowledge, but in nature not content producers? How can their knowledge be shared with others? Let them pair or mob with others to work. Then there could be some others to document and share. At least, the more people interact and work with others, the more chances knowledge is shared or even documented and available to more people.

This all happens naturally and organically. Company can have certain reward mechanism to award the content producers. This is normally an overlooked area. But regardless, the sharing themselves is a natural reward.

Not documenting or sharing on the other hand can turn into penalty such as interruptions and reduced productivity. People may ask around for the same information at work from time to time. Then this information definitely should be put to a wiki page or some how to guide. If certain things are only done once a while, then having a readme file or wiki page is like leaving some notes for the future ourselves.

First of all, for wok-wise, if the products and team ownerships are defined right, there should not be a lot and frequent communication outside teams for collaboration and handover of work. Most of the work can be handled within the team. The team should also have most of the expertise of what they do.

To promote a team culture with high transparency and high visibility, it should be encouraged that most of the communication be made to all team members, including detailed development work. There should be some asynchronous communication place for the whole team, such as slack channels for the team. The organization should break down the communication layers. Communication should pass as few layers as possible to reach the staff employees. Better, organization shouldn’t have that many layers as well.

Direct messages between two team members should be limited to only when the things they discuss are private. Having the communication content available to the whole team, more team members would be aware of what is going on within the team, not only limited to the things they are working on.

Direct message or point to point communication should be avoided to increase knowledge sharing and efficiency within the team. The traditional way of communication involves a lot of point to point communication, such as Product Owner gives some work to the team by talking to the squad lead only, explaining the work and background information. then squad lead assigns the work to a team member, repeating the explanation of the work and passes along the information to that team member. It is more efficient if this communication is done during a user story grooming meeting or team standup meeting. If it is some repeated work or straightforward task, it is better to mention that in the team slack channel instead of only to a single person.

Communicate publicly reduce bottleneck to wait on a single person . If anyone wants to ask a question, then ask to the whole team on a slack channel. Then anybody can chime in instead of having to ask one person through direct message, then another. Even though this might distract more people, but the benefit is that other people may also have the same question, then they will be able to know the answer as well.

People may worry about over communicating, such as not everyone in the channel is interested in the conversation. DM may seem better. But over communicate is better than under communicate. Let team members decide for themselves. If they are not interested, they can ignore that thread of conversation. Making the information available to other people is better then having the conversation privately. Here I want to mention as an etiquette using slack or other tools, always try to use a thread to reply a message, unless you want everyone’s attention on a certain answer. Directly replying other people’s message with another message is a spam.

Outside team communications, if it is any general sharing of knowledge, it is better to use channels related to specific topic. Then any team member can feel free to join the channel. Broadcast is better than passing the information through many layers of people.

Today’s world, email is probably the least preferred communication method. People should be encouraged to use other available methods if possible. The only time email is better is sometimes meetings are arranged unnecessarily when communication could be done via a simple email.

People that schedule meetings should be very conscious about using people’s time. Any meeting is an interruption to developer’s regular work. Meeting invite should be available to anyone interested. However, anyone in the meeting should feel free to leave the meeting if they feel it is not a good use of their time and their presence is not needed in the meeting.

Slack or other team communication applications are not good for back and forth discussion. If that happens during any discussion, a quick call will be more efficient. Verbal discussion will be much better than messages.

No matter what, it is all up to each individual team. What works best and what type of communication they feel most comfortable with, is the best way to communicate for them.

Patrick Lencioni’s book The Ideal Team Player listed 3 essential virtues for a team player. Lacking in any of them will make an employee not a team player and will harm the motivation and effectiveness of the team. The 3 virtues are humility, hunger and smarts.

Humility: Asking each person to be humble might be a high standard. But a team member cannot have strong ego. Otherwise the team may not function well when such a person exists in the team. Such a person may always wants to take credit or show off in front of other people. It would be pretty annoying and make other people feel bad. Also, such a person could be barely teachable. They will endlessly try to defend themselves and find arguments for what they did, even for some minute things. Team discussion sometimes ends in rabbit holes. In a simple word, these people with strong egos always have to be right. Or even what they say has a slight slice of rightness in it, they would spend team’s precious time just to prove that slice of rightness， disregarding what was the objective of the original discussion and what team try to achieve.

Hunger: The team player with the hunger will always look for more to do, more to learn and more responsibilities. They are self motivated and self driven. They want to do more and care about the team’s goal. On the opposite side, a team player that lacks hunger is reluctant to learn. They often says they cannot take a certain task. They also don’t see work. They may avoid trying to spend more efforts on their own to try to figure out things but constantly or readily ask help from other team members and stay not able to work independently.

Smarts: This refers to whether a person has common sense, business sense and understanding, and professionalism. It is not like that everything will be in written format in a work agreement. Whether an employee has the sense of how to behave in a business world, how to interact with colleagues, or what type of work ethics they have or lacking. Whether the person behaves professionally in their work conducts, etc.

Ideally, the hiring process eliminates anyone that is lacking in these virtues. But it is not easy during short interviews to identify what type of employees the candidates would be.

No one is perfect. The persons have all 3 virtues are the natural leaders. The people strongly lacking in one or two of the virtues could be reminded. Anyone that is a mature person and cares about the job can improve and grow on these virtues. But for a team member somehow does not get on board with the rest of the team from time to time, it may be time for the hard decision.

The decision to let a person go would be hard, one is because that team member stayed with team long. Whether they are likable or not, they have been part of the team. Letting them go, would that make rest of the team happy or would that hurt other team member’s feeling? It is hard to tell. But probably a mixed feeling since that is a person not functioning well within the team. It might be a likable person but not capable to do the work, not hungry enough to learn and improve enough. Then after-all other team members have to do more to cover this team member’s work. And that is not fair.

The other part that is hard for the decision is that these people already have certain training and experience about the job they do. It is like sunk cost in economist’s term. Since we already invested in them, it is hard to let go. Any new employee will need to go through training again and pick up knowledge gradually. It is another bet with new employee because we don’t know how they will turn out to be.

“Every large-scale change requires both leadership at the top and the widening and deepening of connections through wooing — not coercing — an ecosystem of stakeholders.” – Greg Satell HBR “4 Tips for Managing Organizational Change”

Successful transformation needs people to be motivated and willing to make the change. It is not something that can be pushed from top, otherwise there will be resistances.

Company wants transformation mostly because there are new thoughts, ideas or processes that they want to adopt. A lot of the transformation do not just happen with one company, mostly it happens around the industry if it is some type of better ways to do business or work. So company leaders may not be the only ones that knows about these ideas. Employees that are keen into these better methodologies may also know about that and are eager to make the changes in their own departments.

To smooth out changes, the more people know about the ideas, the easier the change would be. For large scale broadcast of the ideas, there could be communication from the company, or even an internal conference, etc. But to have things thoroughly discussed and the ideas spread out with deeper thoughts, it is better to let clusters of small group of people to learn about these ideas and discuss about them together.

One thing that worked out for my department was book clubs. Copies of books were given to team members and they read them and meet each week to discuss about the chapters they read. That way even for people not having the time to read the book, they can still benefit from the book club discussions. The books that were read include Clean Code, Working Effectively with Legacy Codes, The Unix Project, Accelerate, etc.

Public channels on certain topics certainly help, but the small group discussions are more effective on discussing and socialize the ideas or some new technologies. Like technical leads meet regularly to discuss things.

Not all team members have the understanding at the same level. But as long as there are advocates of the changes and people with deep understanding of the vision and what needs to be done, they can talk within the team and help to drive the team to be on the right move and thinking.

The understanding of what we want to achieve is important, instead of just giving tasks to teams and let them accomplish those. Team need to fully understand the why and have clear vision. Otherwise it will turn to a cult culture that people seem to be doing the right things like automation, building pipelines, but not doing them the right way. I can give example, such as team put more efforts on building automated UI tests while not having enough unit tests and have a reversed test pyramid. Or team built a pipeline and claim that they are done, while it takes the pipeline more than half an hour to make a build, and another 40 minutes to make deployment. Or a team already have micro services and it takes only minutes to build and deploy. However team members do not merge codes once they are done but keep them in an integration branch. And only merge to main and deploy every one or two weeks.

Though these could all happen during the transition, and it is a continuous improving process and teams are getting better and better. We need more people to have the clear vision in mind and call things out when they see them instead of team being stuck with something seems like transformed process but far from getting to the goal yet.

Team culture is subtle. It depends on the team members and leaders. Each person should feel happy to come to work, feel excited to work on things and contribute to work. They should also feel safe to ask question or express their own opinions.

The senior leaders play an important role on what type of team culture individual teams will have. Whether the teams are under constant pressure of time lines, whether the teams are being criticized when they fail, whether teams have time to experiment on new technologies or make improvement on devops pipelines. Team cultures are not bottom up and solely being decided by team members, but greatly influenced by senior leaders, who influence how mid level managers will interact with their teams.

Ray Dalio’s book Principles: Life and Work showed very good principles for a company’s culture to be highly transparent and highly visible. Except a small percentage of communications at work need to be kept confidential, such as related to compensation, feedbacks during one-on-ones, etc, most of the communications can be made public and shared with whoever interested.

With highly visible and highly transparent culture, information is readily available to everyone. It is not like only certain people hold information like some secrets. That may create back talking or gossiping. With information available to many people, employees can also comment on company’s operations or give feedbacks.

Fairness is critical at work. The opposite of fairness is favoritism or work bullying, which are toxic. A certain person or a group of people are treated either favorably or being undermined or constantly criticized unrelated to their performance. This will result in low morale and low productivity at work and people not engage much at work.

Important things about pairing:

Make sure team rotate on who and who will pair together. Otherwise it creates segregations.

Leave free time at the start and end of the day so each person will have time to check messages, etc.

How much time the team should spend on pairing? My group did 100% pairing, i.e. all coding was done through pairing. Later we changed to selectively choose to pair or work on things individually. From the pairing experience, there are times when pairing doesn’t work well. When the pair needs to try to experiment, when both are willing to try some totally different approaches, it is better that each person tries on their own, and then come back to pair and review the results together.

When the task to work on is very straightforward and simple, it is not necessary to engage two persons to pair on that. Even with rotating who to drive and who to navigate, it would become boring to pair on super simple tasks. It will be better for the pair to split the work and each work on their own. Then after they are done, review each other’s work.

The time when it is very good for pairing is when some design thinking is needed, then through pairing, 2 persons working out this phase together not only gives better design, but also having both of them gaining good understanding on how to proceed if they are going to split work to work on their own. This is better than each person just learn from reading other people’s codes and interpret the intention of the codes based on their own understanding.

When there are complicated tasks, pairing or mobbing will be more effective to tackle them together. It is also very good learning time to let junior developers to learn and grow.

Pairing is most effective when two persons are at about the same level relative to the difficulty level of the task. Both sides contribute thinking and ideas. No extra explanation is needed when both understand what is considered best practice or what design patterns to use.

Pairing is good to bring new person on board in a new area, or it is good to share knowledge. However, if for long term the persons to pair with is always at askew level of skills and knowledge, productivity or even team dynamics won’t be good. This is not a problem of pairing, but a problem of team structure. A team should have mixed level of team members. At work, we normally have mixed difficulty levels of work. Then pairing with different persons work well for different types of task at work.

Seniors pair together can tackle very complicated task or work out a good design for the product. While senior pair with junior gives the junior an opportunity to learn from a senior person, but it also allows the senior person to teach and practice mentoring and communication skills. By explaining things to the other person, it will help the senior person to work things out too by talking loud what is in their mind. Junior and junior pair together both get more opportunity to practice and improve on decision making.

Some groups practicing pair programming try to hire many junior developers to reduce cost, having the thinking that two person together will provide better quality of codes. However, this doesn’t work that way with complicated task or when good design is needed.

One thing to watch out for is pairing doesn’t really give enough opportunity to an entry level person to grow into a good developer, or it maybe a very slow process. To become a good developer, it requires abundant coding and trying things. Having some side projects or hackathon will work better for that.

Pairing is something that has a long history dated back from XP programming. We embraced pairing during the digital transformation. The biggest advantage the teams experienced was that the culture of the team naturally changed when people rotates to work on different things together.

When people work by themselves, silos are created within the team. Even when people occasionally get together to pair or mob, people tend to pick the persons they want to work with. After a while, you may see segregations within a team. Spread of knowledge is not even but linear.

We talk about encouraging people to move around to work on different area of the application or system, it is actually not that easy for anyone to start with a new area. An half hour knowledge transfer may not work well depends on how well that is done. Very often, the person working on the new area may have question or being blocked by something and needs the one with knowledge to help. It would be an interruption to the other person’s work. Or the other person could be busy and won’t be available. Then it will end up pretty frustrating for the one working on the new area. People may later just avoid getting into new area due to previous bad experiences.

When those 2 people pair then the above problems will go away. There is great benefit that multiple people in the team have knowledge or experience on different area of application. When there are some issues, we can easily find someone to look into it, instead of having to rely on that one single person as how teams used to operate. People can go on vacation without being called because they are not the only ones that know a particular area.

With people moving around or leaving the companies, team will not be left at loss due to the knowledge held by a single person.