Thinking beyond your team

Recently, couple of my teams decided to combine their codebases. It was essentially the same application, written twice over to do the UI for a wizard that went down 2 paths. Their backends do very different things. However, the customer sees a very similar interface.

After having done the migration, there have been some gripes. There is a lot of waiting between time zones. Ownership isn’t clear. Operational setup hasn’t been worked out. Perhaps the biggest issue was that there are two teams for a single codebase. It seems to trip people up when it comes to figuring things out.

So I’ve been asking this one question over and over:

Imagine the other team reported to you (or you were part of the same team). How would you solve this?

Another version of this question:

Imagine you had 15 people in your team across 2 locations. How would you run your scrum processes?

Once you remove the artificial manager/team/pod based barrier, people seem to work it out. This little mental barrier is the root of a lot of problems when collaborating. It is really important for people to identify their tribe. For most people, their tribe is their scrum team. Increasingly, that isn’t good enough to get the best results. At least in my team, we need to expand our view of what our tribe is.

Car crashes and sticking to your lane

My team recently made the decision to not have QA role as part of experience engineering. There were a lot of complains on increased workload and not wanting to do testing, including some valid reasoning around testing not being an area of expertise.

I’ve heard similar complaints when we spoke about creating dashboards and alerts for observability — “backend crap”. When I was a manager a while back, I even had someone in my team tell me he can’t work without a TPM writing the requirements down in the card. Requirements gathering is apparently not part of the job.

I recognise that there is discomfort in breaking out of what we are good at. Being a coder, there is a level of certainty to what we do. To think about customer behaviours and ways to break a system is adding uncertainty. There is a lot of resistance to do what needs to be done. Everyone likes to stick to their lanes.

Unfortunately, hard boundaries make for shit software products. People learn to stop asking why things are done/made a certain way. A level of disengagement sets in. Boundaries take people away from what matters the most: having [customer] outcomes.

I was trying to explain this recently with the metaphor of a car crash. Maybe this will resonate.

Imagine you are in the passenger seat of a car. Your friend is driving you back from a day at the beach. Beating sun and the long drive has made him tired. You aren’t much of a confident driver, so you can’t really offer to help. Tired eyes give way and your friend falls asleep at the wheel. You try to wake them up but Morpheus has trapped him in the land of dream.

What do you do?

Do you say, “not my area of expertise” and watch yourself go hurling into a sidewall? It would be pretty sensible to grab the steering wheel and find a way to get both of you to safety.

This is what most work is like. We constantly have to go out of our comfort zones to make outcomes happen. That is the entire value of an engineer… they solve the necessary problems to make outcomes happen.

2 things to leave you with:

1. When you hire for a team, mix experts with generalists.
2. Explain to everyone that in your team, they’ll have to step out of their comfort zone to make things happen. That they are expected to solve problems no matter where it takes them.

The Bear and shows about teamwork

I love TV shows that show great teamwork. They aren’t always easy to find. Most shows tend to focus on an individual character and their story arc. I’ve been watching The Bear recently and it is one of those.

The Bear is about a restaurant that is in the brink of falling over. Most characters in the show are struggling with some issue in their lives: grappling with mental health issues, grieving lost loved ones, broken marriages, terrible childhoods etc. They bring the internal chaos to work and the there is no room for the individual skills to flourish. People are too busy screaming at each other to think about why they are there or really, to listen to any good ideas. There is strong push to go back to what was before. This feels a lot like many teams I’ve worked with. Maybe less dramatic.

It is interesting to see what gets them out of the rut. Some of it comes down to small changes — devising clever ways to say “sorry” when it is too intense to say it out loud (they roll their fist on the chest), calling every person a “chef” as a sign of respect, making sure the tape is cut properly etc. They have to continue to do non-ideal things to make ends meet. The individuals themselves have to go on their own personal journey in parallel. Some of it is brought on by new perspective from external events or time spent training internships. Overtime, they start to demonstrate to each other it can be done, as a team. Even things like changes in processes stop being taken as power plays or done for adversarial reasons.

Of course, their challenges get harder. Each individual have to step up their game overtime to make it work. However, the most important thing is that they learn to lean on each other. They learn to be candid, but respectful. Each challenge ties them closer together.

And they make great food. Check it out — highly recommended.

Image credit: TVDB

The other shows I loved for its team work is “Star Trek: The Next Generation”. It probably needs no introduction to many: there are so many things to like about it. I just couldn’t noticing how their team dynamics helped them get out of so many issues. “The West Wing” isn’t bad for teamwork either.

Building trust at work

Today I met a friend who has left his job only months after joining. His team lead had huge trust issues. Everything had to flow through him. He made all the decisions. There was a lot of frustration when people were proactive. I’m surprised he spent that long in this environment at all. However, it got me thinking, how do you work through situations like this?

Despite all the corporate mumbo jumbo people utter, it often comes down to groups of people not trusting newcomers. “You must earn our trust”, is something I’ve been told.

How do you build trust when you are the newbie?

There are some basic things you can do. While I am not very structured in how I interact, upon reflection, most of what I do fall into these areas.

❶ Talk to people. Learn about their lives. Be curious about them. This is by far the biggest step you can take towards building trust in any relationship. Show them pictures of your family. Most people I work with have seen my dog 😆. I figured, do I really need to build trust with someone if they dislike dogs?

❷ Emulate them a little. Learn the lingo. Build some familiarity between you and them. People come together because they have a shared identity or history or something. Learn about that and respect their ways. If they like to name their pull requests a certain way, definitely don’t send them a link on how to do it better.

❸ But of course, be yourself. Again… in small chunks. You are not going to swear like a sailor on your first date, so don’t do the same at work either. I mean, sometimes that will speed things up if you “met your peoples”. Unlikely. What has worked for me is to tell bosses that we are not going to standardise measuring velocity or report on story points. Gotta draw the line somewhere. I draw it at bullshit people metrics.

Over time, when there is enough shared understanding, you can take the next steps towards bigger things.

Questions for Engineering Manager interviews

These are some questions I've had written down as we looked for a manager a while ago. Not an exhaustive list or the top 10. Just some questions worth thinking about. Hope this helps.

Motivation

• Why management?
• What do you do to learn more about management?
• What is the most important thing for a team?

Maker Mindset

• Tell me about how you balance team outcomes vs individuals having autonomy to make decisions and drive work forward?
• Tell me about a time you chose to remove a process in the team and simplified? Why? Outcome?

Feedback

• Tell me about a time you had to give someone bad feedback.
• You’ve just been told that one of your directs are not doing a good job in their squad. They are not getting their cards done and often not available for group discussions. What would you do?
• Your direct tells you that you haven’t been doing a good job in managing him. He feels neglected and hasn’t been able to get the opportunities they want in their career. What would you say to them?

Conflict Resolution

• Your direct tells you that they had a conversation with your manager. She found your manager to be rude and condescending. How would you go about acting upon this feedback?
• Tell me about a time you had to resolve a conflict between 2 parties.
• Jane, a mid-level engineer who has been at our company for multiple years, is regularly ignoring coding guidelines, even though they are part of software engineering expectations. When you bring up this issue, she shares that she feels pressured to complete her projects quickly, even hinting that other leaders push her to cut corners. What actions would you take?

Mentorship

• You have a backend direct who wants to learn to be a frontend engineer. How would you go about helping them achieve this?
• Alice is not feeling productive recently. They are getting randomised and pulled in all directions to help with various projects and prod support issues. They are not getting much done for their squad. How would you help them?

Technology

• You have a conversation with a principal engineer, who suggests you should be using pure JS for your experience APIs. How would you go about working through that?

Morale

• You see a direct in low demeanour recently. Little sad. When you question him, he tells you that they are having a tough time in their home. What do you do?

Prioritisation

• Tell me about a time where you had to take on a “big bet” work item for the team. How did you tackle the problem? How did you manage risk?
• How do you prioritise work in the current team? How do you choose what things to invest on at which point in time? (Tech debt vs features)

Wise words from a tall man: playing the long game

Vithun with some words of wisdom: vithun.com/posts/playing-the-long-game

...the longer the game one is in, the more they have got to be able to let something go. And not just let it go, but take it off their mind and start from blank for the next thing coming their way. Reacting to everything is something one does when having a shorter-term mindset.

Leave some balls. Thanks @vithungajendra.

How do you communicate effectively in an asynchronously setting?

This post is part 2 of a series:
Part 1: How to make remote work successful at your workplace?

Write everything down.

For an asynchronous setting, communication can’t happen live. Obvious — I know. However, we have such strong affinity towards live communication methods. Live chats tend to be “high resolution” in nature. We get immediate feedback. In-person (and video) brings more detailed signals from tone, expressions and body language.

Writing happens in low resolution. It tends to be one dimensional. Most of the time, not all recipients fully consume the written material. However, writing can be equally high impacting method of delivery in a distributed environment.

Some benefits of writing:

• Allows for time to think and formulate more relevant messages (adjusting for tone, emotions etc)
• Written discussions tend to be less circular
• Better attribution of ideas and a means to sidestep strong voices
• Searchable, making its impact long lasting — ideas are most impactful when someone is ready to hear it
• Get time back by turning so many BS meetings into posts (example: “what shall we name this service?”)

Few tips from past learnings...

Placement & Format

Not all discussions should be had on Slack. It is important to think about where something should reside in. Use a variety of mediums. For example:

• For guides / read-only pieces — Wikis and blogs do great
• Discussions about specific work tasks — Trello cards
• Big ideas that need shaping — documents, Miro boards
• Sharing news, unstructured thoughts or rhetoric — team channels and emails

Something I often do with my teams is to write a “directional” post in a document and let them edit and comment over a week. Often, the draft sets up the direction and allow the team to tweak ideas and move towards something more widely bought into. One such example was “Our point of view on Agile practices”.

Another practice we had in team channels is to do more “social” chats around product ideas, debating about blog posts, sharing travel pix or building Spotify playlists together. We once had a 469-post thread for discussing Sausage & Egg vs Bacon & Egg McMuffins!

Also, more gifs and fun emojis.

Meetings

Try not to have them. Read more… Meetings are Toxic.

Some can’t be avoided. The issue in a distributed environment is that not all can be present. To combat that, most people record meetings. Thing is, not many recordings are ever viewed later on.

Public posts summarising discussion points, action items, decision points from meetings can go a long way in building trust and avoiding FOMO. It also means that there is a forum to discuss ideas missed out on or raising concerns that can undo decisions. Remember to allow time for people in other timezones to chime in.

Generally, asynchronous work places can offer more thinking and making time for all.

Leaders

As a leader, it is most critical that direction comes down in written format. Even in live setups, writing down direction does wonders. There is less ambiguity and messages lost in translation.

I write biweekly a posts to the team about what is happening in the background. They include things the company is worried about, concerns I’ve heard about, achievements etc. These keep people connected to what is happening.

More casual, candid style writing helps the team learn about the leader and their motivations. Robotic, corporate statements don’t inspire.

Open Slack debates also become a place to set up culture. Encourage people to disagree with you and when they do, praise them. Micro-moments where candid conversations happen can set the tone for how the team works. Written format is great for these as these moments last for much longer.

Concluding thoughts

Building a culture of written communication takes time and effort. Many can’t immediately see the impact of pushing for these. I’ve had many debates over why it is so much easier if we could just turn around and talk to someone instead of having to “type shit out”.

Yes, it takes more effort. At first, you may find yourself having monologues on Slack channels with many readers and no participants. People will contribute eventually. Active channels make for great meeting places to be social and get help from one another. It forms the basis for asynchronous work.

There is an asynchronous version of the team where they are more effective, collaborative and productive. It won’t matter where in the world they turn up to work from. Work can happen in true openness and inclusivity, where there will be so much learning and creativity.

It’s not a crock.

Some of my favourite books (non-fiction)

Some of these changed the way I approach work/job altogether. They sparked something in me that I continue to explore: how do we create the best products and teams that build them.

My "makers" reading list on Goodreads

Currently reading: Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed. Fascinating.

How to make remote work successful at your workplace?

You have to fully commit.

The whole world is going “remote”. But, it is hard to tell if imany places are finding success in a more distributed working model. It is a tough transition. Much of it is because most workplaces continue to operate with the same way they’ve always had. Somethings need to change.

First, we have to understand a small nuance. It matters whether your company is doing remote work within the same time zone or not. If your company has no location diversity, sign up for Zoom and Slack — you’re good to go.

For most places, remote is a chance to transition to more location diversity and offer flexible working conditions. Remote work can still happen “live” if everyone has a large amount of overlap. However, as more locations or flexible work hours come into play, “asynchronicity” start to be hugely important.

Asynchronous work is very different to how live work happens. Meetings don’t work anymore. Key players find themselves being needed all times of the day, which is super stressful. Answers aren’t always a call away. Traditional means for workshopping and collaboration just doesn’t work!

Leaders, especially, find asynchronous work really tough. It is a new level of trust (or lack of control). Most leaders have built their career on being charismatic talkers. They prod, steer, influence and inspire their people through words… live. Asynchronous work means these things are no longer straight forward to achieve.

Only way to transition to working remote + asynchronously is to get onboard fully and lead the change. If the commitment is lacklustre, what you will find is that remote work has low yield. It will create a class system within the organisation. Priority and decision making will reside in co-located regions (“HQ” vs “remote” workers). It will naturally lead to the conclusion that remote setups don’t work.

To make an asynchronous workplace work, start by identifying what needs to be live. Be very selective. Live activities tend to be operational aspects of maintaining a product and management tasks like 1:1s. Think deeply about how to set these up in a distributed format.

For activities that don't need live interactions, start to formulate some basics around these:

• How do you communicate effectively in an asynchronously setting? (Read part 2)
• How do people find each other to collaborate?
• How do you move fast in a distributed environment when decision makers aren't in the same place?

Hope this gets you thinking 🤔. I'll follow up with my thoughts on the above questions soon.