Here are some thoughts on my experience working in the tech industry.
You can’t manufacture team culture. It’s the result of organic habits and behaviors that a group of people develops over time, which is also the reason why workshops and top-down change initiatives meet so much resistance.
Don’t have a meeting if you don’t have an agenda.
If you can end a meeting early, do it.
Don’t use meetings for status updates. A team should keep track of everyone’s status in whatever project management tool that it uses.
Nobody is “productive” for eight hours a day.
Presentations and keynotes are useful to showcase work and get feedback on it. They’re a terrible way of conveying complex or highly technical, context-specific information like data analyses and research work.
Don’t take questions during a presentation. Ask people to take note of them and ask them at the end.
A presentation is never as understandable as you think it is. Most of your audience probably won’t grasp most of the content.
Written feedback is better than verbal feedback. Written feedback (hopefully) requires people to think deeply about what they want to say and how. Oral feedback is often impulsive, incomplete, shallow, and lazy. It is also poorly remembered.
If you believe that an idea, a design choice, a code snippet, or process needs improving, then do a proof of concept yourself and present your solutions. Telling other people to improve on something you have an issue with is in poor taste, especially if you have the skill to do it on your own. Also, speaking in we terms diffuses obligation (e.g., “we need to fix \(x\),” “we need to become better at \(y\)”), and is a waste of time. Talk about what you can do and take on that responsibility voluntarily.
Written communication should be the default, especially if lots of people are involved in a task. However, email threads and chat are not a good way of expressing that communication. There should be a structure around it. Even something as simple as a shared Google Doc that people can comment on is better than chat and email threads.
Show, don’t tell. Make visual representations of your ideas. Don’t expand too much on topics that only some people in the room can mentally visualize. They won’t tell you that they’re not following the conversation and this adds confusion later. The more technical or abstract the subject is, the more critical it is to make it visual, tangible and understandable. Analogies are an excellent tool to use in these situations.
Achieving consensus is not a function of not hearing any objections in the room. People may disagree and not say it. It’s exponentially harder to get everyone to agree on something when you are many. A more realistic goal is that everyone on the team should be OK with moving forward with a decision, whether they like it or not. It’s called disagree and commit. The focus should be on the goal of the group, not the preference of the individual. It takes group maturity to reach consensus.
The psychological make-up of your team determines how quickly you reach an accord when you’re stuck. Also, if your disagreement with a course of action is such that you can’t commit, then you should get out of the way. It could mean that you pull yourself out of the project so that you’re not interfering (consciously or subtly) with it. You avoid dissonance within yourself and allow the people who committed to go all in.
If your seniors (or managers) are people with whom you can’t disagree because they assume to “always be right,” then leave that team (or that company). If that’s not the case, but instead you have a hard time expressing your opposition, then you might be too agreeable and should work on that trait of your personality to avoid becoming resentful.
Policies are experiments. Consensus allows you to try out policies until you learn or know better. That’s why unanimous decisions are overrated. If you view your team development as a trial-and-error process, then there’s no need for everyone to accept everything every time. As long as people have no problems with a decision, you can always move forward and make adjustments on the way. In the long run, you should test everyone’s suggestions, and they may prevail or fail.
When working with analytics, building tools is more rewarding than informing people.
Some things will, unfortunately, be beyond your intellectual ability to grasp or deliver.
Given the same amount of time, learning about many things is more useful than trying to know them all.
What doesn’t get practiced, gets forgotten.
When your performance becomes a function of your manager’s (or client’s) mood, it’s time to leave.