Continuously improve while remaining pragmatic.
Trust. Transparency. Candor.
I focus on trying to build trust with my team members, and ensuring they can build trust with each other.
(More thoughts coming here soon)
I’ve stopped trying to use the word “agile” or “Agile”, with a capital A. While I think my focus is around truly having agility, and I like many of the aspects of “Agile”, I think there’s too much attached to these words now that detracts from my own philosophies.
I don’t care how it’s done (I have some ideas), but I want to ensure my teams are setup to continuously improve. The tools, mechanisms, and processes (or lack thereof) are decisions that I want the team to organize themselves around. If they are empowered to focus on continuous improvement, they will be able to evolve these over time.
(almost) Never Say Always. (almost) Always Avoid Never.
I have my own set of experiences that range from startup, small business and big tech. I’ve been on both the individual (IC) software engineering side as well as the management side of things. However, these are just experiences that I’ve tried to extract learnings from and form into my tenets.
I strongly believe that the best traits in engineering are not individual’s technical ability, but our ability to learn, communicate, collaborate. Software engineering is done in teams, and a team of individuals will not be as effective as a cohesive team that can rally behind an exciting purpose. If you have data that proves otherwise, I’d love to chat!
My philosophy is that we must remain pragmatic when approaching software engineering. The words “always” and “never” cause me a lot of discomfort because I believe we should always remain open to what options we have, considering the pros and the cons.
Engineering is all about analyzing the tradeoffs we can make in our paths forward. I think this is something we should exercise and build expertise in. “Always” and “Never” will often (see what I did there?) cause us to rule out opportunities before having the chance to analyze them.
For me, the “no hello” concept really resonates with me. This is something that I greatly appreciate when colleagues reach out to me and also something that I try to ensure I am practicing in all of my communication. First off, this does not suggest that I don’t want to hear from you… Quite the opposite, really! I want to hear *more* from you!
If you haven’t heard of it, the concept is quite simple. When using any sort of text based communication, there’s a really great opportunity to help the effectiveness of asynchronous communication. Instead of sending a single introductory message to start a conversation (such as “hi”, “hey Nick”, “good morning!”) and then waiting for the receiver to reply, you can remove an entire back-and-forth step by simply including (or following up with) your intent.
Before: “Hey Nick!”
After: “Hey Nick, I wanted to ask about X. I think that my understanding is Y, but I was hoping you could let me know before the meeting Z about whether or not this is accurate”
Before: “Good morning, Nick!”
After: “Good morning, Nick! I wasn’t able to get X done on time, so I am trying to get it done by Y as the next best option. We encountered problem Z, so I just wanted to give you a heads up on it. If you have any concerns about that, just let me know.”
Not only does this greatly reduce bottlenecks in communicating information between two or more people, but there’s also anxiety reducing effects of communicating this way. I think this is another important note when you’re considering how to optimize your communication with people.
For example, if your manager sent you a message that said something like “Do you have time for a quick meeting in 10 minutes?”, you might be left with racing thoughts. “Why do they need to meet with me? What do they need to discuss? Am I performing okay? Did I mess up somewhere? Is everything okay? I wonder what this is about?”. If this doesn’t resonate with you (you’re lucky!) please keep in mind that this does happen for many people. Even if the sender is not your superior, the same type of anxiety can come up when there’s complete ambiguity about what needs to be discussed.
And just another reminder to close off on this: I *do* very much want to hear from you. Please message me whenever you want, and I will respond when I have availability. But please do include as much context as you can so that I can communicate effectively with you. I will try to do the same for you as well.
Where I’m Trying To Improve
Something I’d like to keep in mind when I eventually take on another newer team is that while I find it critical that I learn about the team before making adjustments, I need to be comfortable putting suggestions forward. There is a balance between disrupting the team and helping guide the team, and I have historically been too “afraid” of being perceived as disrupting.
I enjoy working, creating things, and being able to help people. Genuinely. These things make me feel fulfilled. Diving into a startup for the first 8 years of my professional software engineering & management career essentially reinforced this for me.
As I grow in scope of management and leadership responsibilities, I need to ensure I do a better job of showing others that they have a safe place to disconnect and take time away from work. While in my role I want to ensure my team members know that I will try to support them if I am able to (key words here are if I am able to), I do not have that expectation of them when they are away from work.
This is something I need to do a better job of communicating and demonstrating. I do not want the support I want to offer to my team members to be something they feel they need to emulate to be successful.
Too Much of Everything All At Once
I have a very bad habit of diving into the deep end of things I am very excited about. As a result, I drop everything else, and then eventually burn out on the new thing I jump into. I’m often left feeling like I have made “some” progress on a bunch of things, but nothing that feels complete.