🔗Seek Understanding

My manager and I are discussing an interesting topic at work at the moment - how do we communicate what we do as engineers?

We were talking about how to set better expectations with stakeholders but it's since turned into something bigger - what do we actually do?

Deliver value to customers is one answer and it's a good start. On smaller projects that's probably all there is to it. But bigger projects mean bigger uncertainty and often require working with other engineers or teams of engineers. It's not always clear how you can best deliver value to customers.

My manager sent me this video, "It's Like Coding in the Dark: the Need for Learning Culture in Engineering Teams" - Catherine Hicks, that talks about software engineering as more of a people thing than a product thing. I found it thought-provoking to say the least and I ended up writing a massive response to him. It was so massive that I decided to post it here as well.

The video talks about the paradox of a learning culture, "It looks worse before it gets better". It reminds me of an article I read recently, Cultivating depth and stillness in research - Andy Matuschak, where Andy shares some thoughts about how he thinks about work. He's found inspiration from this quote and it resonates with me as well.

"Mathematics is a process of staring hard enough with enough perseverance at the fog of muddle and confusion to eventually break through to improved clarity." - Bill Thurston

I think the real difficulty here is fostering this culture within the team but communicating outwards to stakeholders in terms of performance and expectations. Maybe it's as simple as adding a decent buffer to our expectations so we have room to learn. I've heard of doubling your estimate but I've even gone as far as "triple your optimistic estimate" before.

Maybe it's also about shifting the conversation from how long is the project going to take to more "this is what we've worked out so far and this is what we're still uncertain about". I think it might shift the focus more from "getting through work" to "reducing uncertainty and increasing understanding".

It also touches on how we work with other teams. We all need help from other teams at some stage and how we do that matters. We have to be empathetic if we want sustainable performance. Most people are willing to help but they're not so willing if they feel like they're being hand-balled your work. I've worked with contractors that didn't hesitate to work like this. Other teams noticed, gave less of their time and performance diminished.

Engineers respect ambition and naturally want to work with people that are genuine about it. I think this is because big goals require deep understanding and being close to someone with deep understanding means you can learn off them to develop your own skills and understanding.

I sent the stillness article to a colleague he appreciates it because he's interested in it and it's relevant for him. He sees it as a way to grow his skills and understanding but there's also social element too. "Cadell thought of me when he read that article and that's pretty cool". It's easy for him to do the same. You've done the same for me with the learning culture video. We're working together to develop our understanding of something we're interested in.

I constantly think about the paradox between progress and community. If your goal is just to socialise then it's hard to develop relationships in the long term because there's no substance behind it. You have to focus on progress, even if other people don't agree with your direction. You have to trust your gut and pursue things because ideas are easy to criticise and hard to execute. It's easy to get stuck doing the safe thing and doing nothing. Jason Fried talks about something similar in Idea Protectionism. Over time, this striving for progress turns into community. Kane Lambert retired from Richmond last year and said he won't remember his games or achievements as much as the people he did them with. It's a paradox because striving for progress can build community yet striving for community can leave you with neither.

Maybe it's as simple as "seek understanding and bring others along with you". When you've worked something out, share it. Write a document, talk to people about it, see if your team is interested. These simple things can build relationships and community in the long term.

That's how I'm not thinking about working with other teams. If I communicate my problem well, include the right level of detail, explore what I can on my own and sound genuine in trying to do a good job/solve an interesting problem/learn something/understand something better then teams and people respond to that. It gives them an opportunity to learn and understand too.

Another team jumped on the problem I raised because they wanted to understand and wanted to help me and I made it as easy as I could for them to do that. I gave them an opportunity to contribute and learn and we all ended up with a greater understanding. We all benefited and we did it together.

Lazy questions take resources to answer and good platform teams can identify them and hand-ball them back. Good questions build understanding, build community which builds long-term, sustainable performance. It's not as simple as "another team has to help me". It depends on how you work with that other team.

The path to performance is wonky. If we stick to the happy paths we will only find local maxima. Real performance comes from understanding, through both certain parts and uncertain parts, by yourself and with others. In the end, you'll often find you couldn't accurately predict which parts where certainty and uncertainty would be anyway, only that it's there. The certain parts can be surprisingly hard and the hard parts can be surprisingly easy. Reality has a surprising amount of detail. It reminds me of "Everything will be alright in the end. And if it's not alright, it's not the end."

That generally means thinking about performance or productivity can be counter-productive. If you focus on what needs to be done and how much time you have then you you're not actually working through the problem. They're distractions. I think this line of thinking can lead to performance anxiety and maybe imposter syndrome. Having a more senior role only contributes to this further and is something I've certainly experienced. I remind myself that if I go where the work takes me then the results will take care of themselves. Obsessing over productivity and what results I want isn't productive, even if it feels like it is.

It reminds me of one of the concepts in The Toyota Way and Lean Manufacturing, "go to the gemba". It means "go to where the work happens" or in other words "get out of your comfy chair". It means for managers to go down to the manufacturing line to see what's happening for themselves to build real understanding. In engineering, I think of this as following code, writing code or asking questions sooner rather than later.

This is also a concept in Zen, "the map is not the territory". It's too easy and comfortable to conceptualise mental models and play out scenarios in your head rather than testing and validating them. Doing things can be uncomfortable because you're going to find out if you're wrong. If you shy away from this you'll only get more in your head and more uncomfortable when you eventually do something and you're wrong. You'll think "how could I have avoided this?". The real solution is do more so you make less assumptions and become more comfortable with being wrong. If you stay up in your head then all you're doing is stroking your ego.

The complexity of reality doesn't fall into neat categories and boxes, you need to get a feel for them and go where they take you. You're in a relationship with the world and neither exists in isolation - you're both dynamic, changing and constantly interacting with each other. Results are just as much what comes your way as they are what you want to happen. Trust your intuition, practice, back yourself and seek understanding.

This really blew up. I didn't decide to write an essay here, I just started writing a reply and it happened to turn into an essay. Maybe that means I'm starting to practice what I preach.

I guess the tl;dr of all of this is "optimistic estimate * 3".