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.

Do all software engineers care about customer impact?

I got into a fun chat with my friends about unengaged people at work. Do software engineers care about salary, solving a problem technically (discovery), shipping, or does that work has to have impact in someone else’s life? Of course, different people find joy in many points within this spectrum of outcomes.

Interesting question surfaced: is it that some people don’t find joy in having impact in others or have they just not had the opportunity to make that deep connection to their work? I mean, nothing wrong with just finding joy in solving problems, right?

I referenced 2 stories from my past.

I used to go to church multiple times a week and be involved in many religious activities. I was happy and I never really thought past the bubble I was in. Then my circumstances changed with where I lived, my closest friends’ life circumstances etc. It led to me inspecting the bigger “why’s” of life. As a result, I incrementally focused my energies elsewhere and dropped out of church.

Second story was just me as a software engineer. I loved experimenting with new technologies and making fun little UI apps. As a teenager, I had an obsession with how traffic lights worked. I found it really fun to code road junction in Java Swing UI. It was a fun way to learn Java but also… just liked figuring out how things worked.

Then I made a jump to building some iOS apps with my brother. I’ve written about this before. Watching us have direct impact in someone else’s day was just incredible. I was working for Vigil Systems at the time where we guaranteed 15% reduction in public transport accidents (sketchy memory on this metric). These things mattered to people. The direct interaction and knowing how my work helped people was a wonderful feeling.

After that, I always wanted something more. It wasn’t just enough to write good code or ship things quickly. I wanted to know my code made a difference and it helped people to make time or be better off in some way.

So, is it that some don’t get to experience this moment in time that helps them break out and think beyond their Jira cards? If you are starting off in a big technology company, it is really difficult to have this direct connection to customers to begin with. Most developers I work wth never had to explain to a customer how to find a feature in the interface they coded in. By the way, it is extremely frustrating to see people struggle with what you’ve built.

This image came to mind… this is Maslow’s hierarchy of needs:

Are we just thinking about people in different stages of this pyramid? Does everyone have the opportunity to attain self-actualisation? Does self-actualisation mean having direct impact in others?

I think it is pretty important to generate that connection at some point. But we should remember that sometimes, we find meaning in having impact in others’ lives… and sometimes, discovering is just as important. The very act of making and having fun can lead to things. We don’t have a clear purpose in life. So these competing forces — this chaos — keeps us vibrant and moving forward.

Whatever it is for you, I am hoping you find engagement and joy at work. It helped you stay motivated. If your current work doesn’t give you that, find something that does.

Related article to read: How to burnout a software engineer, in 3 easy steps.

Play the long game with people, the short game with outcomes

Recently, @henry sent over my 2020 performance evaluation I had shared with him. I was just about to go from Principal to Director role. I'm still trying to get good at this. Such wonderful advice from @AC. Thanks boss!

Play the long game with people, the short game with outcomes. Knowing how much to push, when to push and how hard is an art. With technology decisions its pretty easy, there is often a right answer and a wrong answer, often the wrong answer is no decision. However with people its a bit different and Dineth can show his frustrations at times when someone is not keeping up. Dineth is great at setting a high bar, this year he will have the opportunity to set a high bar, coach and help his team to hit it but also Dineth will need to make hard calls when someone isn't going to be able to make it. This takes time and practice and I would like to see this be a big focus of his this year.

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.

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)

Conflict Resolution

Recently, my friend shared this story over dinner. He is an iOS developer.

He had been tasked to create a core component for his company’s design system: a container view that sweeps over other views. But there was an issue with how padding was applied. The designer in charge of the component insisted there should be a fixed padding set for content. Most developers who used the component wanted to define custom padding. He was getting lots of requests by others in the company saying their designs can’t be achieved with the new container’s implementation.

Those who worked with me on frontend projects know, bad margins and padding really drives me crazy. They seem to be the trickiest thing for large companies.

My friend goes back to the design partner to change the requirements for the padding. “Let’s set it to zero and let people put things inside a layout view”. The designer explains, “design system needs to be opinionated; all views inside the container need to have the same padding set for consistency”. The tennis match was one of stamina. Conveying how practical usage is suffering didn’t really matter. My friend got tired and gave up after running around the court.

Conflicts like this happen all the time. Perhaps, it would help to think through a framework that helps both parties arrive at shared understanding and agreement.

—

Eliyahu Goldratt, in the book It’s Not LUCK, guides conflict resolution towards finding common objective. Each action in conflict is motivated by a requirement, which in turn, is motivated by an objective. If we can work back to find the common objective in a conflict, we have the opportunity to inspect underlaying assumptions and work towards resolving the conflict.

So in our story, we have…

Developer: [A. Leveraging the design system to unlock consistency]← [B. Flexible system that matches feature designs] ← [D. Remove default padding]

Designer: [A. Leveraging the design system to unlock consistency] ← [C. Consistent component behaviour through fixed values] ← [D’. Apply default padding]

My favourite thing about this framework is its invitation to show empathy. It forces us to inspect motivations on both sides. Conflicts are part of working as a diverse group of individuals. Being able to understand differences and learning to view problems from many lenses helps teams do amazing things.

—

Let’s take another piece of wisdom from (the super awesome book) Crucial Conversations by Kerry Patterson to help us.

Often, a conflict exist because each party doesn’t have the full picture. Much like a Venn diagram with two partially overlapping circles, each party has unique knowledge with some shared understanding between the two. We should approach conversations with a level of curiosity to close the gap on shared understanding (bring those circles closer together). What do you know that they don’t? More importantly, what do they know?

Going into a debate thinking you want to “win it” yields no favourable outcomes; only annoyed people having formed a poor opinion of you.

Again, this is sounding a lot like empathy.

—

A. Leveraging the design system to unlock consistency

Going back to our conflict, I played the designer and debated with my friend. We both asked “why” a whole bunch and tried to explain the differences of theoretical and practical issues.

This is where we arrived (if you care for technical details)…

Some containers describe layout patterns while others define interaction patterns. For example, a Card is a way to lay content out. A Dialog or a Split View may be more of an interaction pattern. Perhaps, we need to have an a rule in the design system on how to approach these two types of components. It make sense for layout views to pad content. How about interaction patterns? Perhaps the rule is to pair interaction components with a layout.

This seemed like a path forward to figuring out how to resolve the conflict.

—

Conflict resolution is all about empathy. Empathy builds great teamwork, which builds great products.

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.

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.