Eric — README

This post is inspired by an awesome article (Thanks Brennan McEachran 👨‍🚀) I recently read. This document is a living document (updated 5 times now since its first version) and I will update it while I learn from my daily hands-on experience.

Disclaimer: This post applies only to me, and in no way should be considered to apply to any other teams or managers at an employer.

About Me

Software Developer. Solution Designer. Team Lead. I am passionate about team work delivering valuable software to customers.

This README is about what I believe, how I think and my ways of working. Any feedback is welcome.

Your beliefs become your thoughts, Your thoughts become your words, Your words become your actions, Your actions become your habits, Your habits become your values, Your values become your destiny.

- Mahatma Gandhi

Perfect The Job I Have

There is no perfect job and every company has its own challenges. I rarely complain (complaints do not help solve problems). I love to hear complaints and see them as opportunities to improve.

It is not my ways of working. As an individual, I have my own preferred ways of working. However, as a lead, what matters is the ways work for team instead of me, and the ways it worked in other teams are unlikely going to keep working in current team or current individuals. When anyone proposes changes to ways of working, team discussion needs to be organised so that all opinions are tabled and everyone has a chance to influence the outcome.

Open to changes or experiments. Greatness comes from thousands, perhaps millions, of small improvements done over a long stretch of time. I do expect team to propose changes to the ways we work in order for us to be productive and efficient, fun, or anything. I love to be challenged and hear complaints or what’s not working. It is not about proposing different ideas but identifying problems. Rather than simply say Yes to all experiments, I would take one step back to understand problem or why, facts, expected outcome (how will we know if we succeed) and ways to measure if possible. Part of my job is to move team forward, if there are disagreement and I am accountable for the outcome, I will make decision based on fact, external opinions and my judgement. There are rules and processes but I personally prefer lightweight and fewer ones when possible. Type 2 decisions is an interesting concept came from Jeff Bezos.

I have opinions. This does not mean they are correct or you should blindly believe them. Please disprove me so that I can learn with you.

I look for people who will say no to me. I look for people who have their own mind. I rely on my own confidence and my own judgment to have people around who will give me contrarian points of view, but I want to see all the pluses and all the minuses and then make the cut. And that’s the job of the decider.

JOHN KERRY

Early and continuous feedback and iterate. I prefer iteratively solving problems over “big bang”. Early and continuous feedback helps build trust and collaboration, improves quality, avoids rework, implies real progress. See how team gives its early feedback to improve quality of design. Another great example is CI/CD and MVP. I believe refactoring is the best part of writing code therefore refactoring and small wins, etc are very encouraged and appreciated (and be transparent on the changes for tracking and communication purpose)

Start small, begin learning and make progress

Start simple and then iterate

I do not simply follow process. Simply following process does not guarantee to achieve expected outcome and solve problems. As I mentioned above, I start with problem (if team does not have the problem, what’s the point to introduce a process or solution?), learn from the existing process and see if it works for team or customise it (there is no one-size-fits-all process). For example, simply executing scrum ceremonies does not mean the team is agile.

First Team Mindset. The original idea came from Jason Wong and it is about improving the quality of leadership and management practiced. I think this brilliant idea is not only applicable to a team of leaders but also a team of individual contributors. One of team norms is to help other success.

Nothing destroys productivity like an interruption. Once you are interrupted, you have to start all over again. We are experimenting to have no meetings for developers for 2 days a week and keep meetings either in the morning or afternoon to have large blocks of uninterrupted time for work. Meetings also need to have agenda or expected outcome/goals which helps team to think about the purpose of meetings and who actually are required. Attending meetings also implies they have higher priority than others, so make sure stakeholders understand impact (i.e. delivery and goals that we have committed). Last tip is considering whether multiple meetings could be combined together (five-hour meeting is better than 5 one-hour meetings?).

Priority. Time is not always enough. We work in an environment with lots of constraints that often requires us to make prioritization calls. The answer to “If we could only do one thing, what would it be?” helps us decide what next priority is. I believe in “Less is more” which empowers us to focus on what’s relatively more important and “Do One Thing and Do It Well”.

Social contract. Getting team to agree with such contract is useful for team to understand what expectations team members have of each other, and give everyone a feeling of control and security in their relationships with their teammates, and cover how team will work together and support each other. There is no right or wrong answers but team agreement.

Individuals and Team Growth

I believe a job develops our skills, and benefits customers and business.

Regular 1:1. Human beings are naturally different and diverse. The purpose is to understand and align with each other, and help me make you successful and better by discussing your strengths, what motivates you, things that you are not interested in, career plan (why, how, investment, etc), feedback/observation/next challenge, and so on. Your success is my success. If you fail I am here to help you success.

Empower you to be a decision maker. I won’t suck up all the oxygen (i.e. hard problems) so that team could grow and be better than they already are. Creating a problem-led environment and rotating feature lead role within team help everyone, if they are interested, have a chance lead and own an end-to-end delivery of solutions to problems. I ask and discuss expected outcome or goals and often ask “What do you think?” because I believe that leading with questions (very hard), not orders, creates a team of thinkers not order takers (I am strongly influenced by this). I am also last to speak.

Engagement and Collaboration

As an individual, I do not like command and control management style. However, as a lead, it depends on the team’s preferred ways of working. It is perfectly fine when team needs someone to work out solutions and activities required to implement the solution, and team just follows and executes the plan. Throughout my career, I’ve worked at a number of teams and found most people like to solve puzzle and feel inclusive. As a lead, I always think/plan ahead. I could choose to come up with a plan (i.e. what should team do in next sprint) and ask team to execute, but I wouldn’t because I think it is worth creating engagement and collaboration to bring team along the journey (in other words, I do it for the sake of doing it). As a lead, part of my job is to create an environment for team to work together as one team.

Make them awesome. Give them the freedom to explore, disagree, and collaborate. Embrace the messiness of teamwork — it’s an investment, not a tax.

Force collaboration by breaking silos, removing knowledge silos and removing mediator. Creating opportunities where people can connect helps build trust and improve quality, minimize rework, productivity and efficiency. A few examples are

• Ensuring Product Owner to approach problems with outcome, not solutions, and bring business requirements, problems and deep domain knowledge to team to help team solve right problem (I strongly believe in this)
• Having a feature lead role helps business and technology people to solve problems together rather than throw stuff over the fence
• Brainstorming options or ideas with broader audience
• Pair programming, non-bookable time for collaboration activities, i.e. story kick-off, PR review, etc
• Redefining QA as Quality Assistance or Quality Coach who gets involved before development to help define quality, rather than being engaged after development as a quality assurance gatekeeper
• Embracing “you build it, you run it”. It is about breaking silos and upskilling each other by sharing knowledge and insights.

Autonomous team. As a lead, I share as much as I could and give team power by providing team with enough context (i.e. process, point of contact, access, etc) it needs to become self-directed and self-organised. Part of my job is to coach team to make myself redundant.

Prioritize team delivery over individual delivery, full stop.