Summary

A lead engineer reflects on the practical aspects of Agile methodologies and the importance of mentoring and knowledge sharing, emphasizing the value of admitting when one doesn't know something and the power of collaborative learning.

Abstract

In "Confessions of a Lead Engineer," the author admits to not having a textbook definition of Agile but stresses the importance of finding processes that help teams deliver solutions quickly and effectively. The article suggests that Agile practices should be tailored to each team's needs, advocating for regular retrospectives and a culture of experimentation to drive continuous improvement. The lead engineer also shares insights on mentorship, highlighting the benefits of saying "I don't know" followed by a commitment to discover the answer alongside mentees. The piece encourages openness in meetings, the value of asking clarifying questions, and the importance of setting an example by acknowledging gaps in knowledge.

Opinions

Agile should be about practical application and solving problems rather than adhering to a strict set of practices or meetings.
Regular retrospectives are crucial for teams to reflect and evolve their work processes.
Mentoring is most effective when it involves guiding mentees to find answers rather than simply providing them.
Admitting to not knowing something is challenging but crucial for personal growth and fostering a culture of honesty and continuous learning.
Overcoming the fear of saying "I don't know" can lead to better understanding and collaboration within a team.
The use of acronyms and lack of context in meetings can be barriers to effective communication, and team members should feel comfortable asking for clarity.
The author values the act of learning together over the pressure to appear knowledgeable at all times.

Confessions of a Lead Engineer

Confession #1 — When you talk about Agile, I don’t know what you mean

Don’t get me wrong, I know you’re not talking about whether I can touch my toes or do a backflip.

I’m passionate about finding processes and practices which help teams deliver solutions for customers quickly, safely while solving the correct problem. However, if you were to ask me the differences between Agile and Scrum or extreme programming I’d probably just look at you blankly.

Do you mean that you do a standup every morning, or do you meant that you iterate your product based on releasing little and often? Do you follow test driven development or maybe do some code reviews?

Do you know what you mean by Agile?

Each of the Agile frameworks have good practices, and probably some that aren’t going to gel for your team. Every team is different and every project has different requirements, so why would one process work for everything?

My advice is the opposite to Master Yoda: “Try, don’t just do”. What I have found most important when working on agile projects is an attitude of experimentation.

The most important question to reflect on is:

“Do you have a regular retro, and does it change how the team works?”

If you have this in place and a willingness to experiment for the sake of progress, then all the rest will fit into place. Find practices which work for you and your team, but have them be the solutions to problems, not a prescribed set of meetings or activities that you do to satisfy a buzzword.

If you never have any ideas at retro, maybe it’s because nothing changes. Unfortunately it’s a vicious circle — if no one sees a change, they’re less likely to think about what could change. Take some advice from MJ and start with the (hu)man in the mirror. If you start driving change and get excited about it, others will follow.

Confession #2 — I don’t actually know that much

I’m passionate about mentoring people. I love to see them grow and improve, and more often than not, I’ll also improve through the act of mentoring someone. Recently I’ve been mentoring a lot of people who are relatively new to software, and a few who aren’t. One thing that you might find surprising is that I often have to say “I don’t know”.

I’ll normally follow it up with “but let’s find out together”. That qualifier is probably why I still have a job. The important part of my job is not retaining information, but knowing where to find it and knowing what good looks like. Seeing you use these skills to find an answer to a problem is far more valuable for your mentee than just being told.

(If you want to read more about my thoughts on mentoring, please have a read of my article how a toddler and two babies made me a better mentor.)

Meetings are another great opportunity to prove how little you know. Whether it’s an overuse of acronyms, or you’ve missed the context, or the subject is just not being explained well, it’s likely that you’ve been confused in a meeting before. Whatever it is, just speak up and ask for some clarity. I can almost guarantee that there’ll be someone else relieved that you asked the question they were thinking.

There’s a popular quote that the hardest three words to say are “I love you”, but for most of us it’s “I don’t know” (arguably four words, but go easy on me!). It’s hard to admit that you don’t know when you’re in a senior position, and people have expectations of you. The temptation is to try to blag your way through it. I’ve done this before, and I’ve seen other people do it too. It’s not worth it. You’ll embarrass yourself more if you’re caught pretending to know. Better to set the example that it’s ok to not know by saying:

“I don’t know, but let’s find out together”

If you’re thinking of joining medium, please consider using my referral link — https://richard-t-bell90.medium.com/membership