Hello! I am Brendan Best and I have created this manual as guide to working effectively with me. With a new piece of software, or equipment you’re more likely to succeed, more quickly, if you have some idea ahead of time how it works. In a similar way, this manual is intended to introduce me to you and help you to know what to expect when working with me.
I have worked in one role or another, and with a large handful of different titles, as a leader in software engineering for over 20 years. During that time, I learned that I am motivated first by the desire to optimize results by optimizing the experience of the people working toward achieving those results. I have held leadership positions in a range of industries and contexts from marketing communications, to education and training, fintech, IoT, and healthcare, in international consulting firms and local bootstrapped start-ups. I am happiest and most effective at any place my efforts contribute positively to teams’ ability to deliver exceptional results, do so sustainably, and as much as possible, joyfully.
“Find your replacement.” That was one of the first instructions I was given when I started to lead development teams. Core to that direction is a principle that none of us should become irreplaceable. Valuable always; irreplaceable, never. I extend that to my belief that a leaders’ core responsibility is to give shape to self-sufficient teams that have acquired and adopted their leader’s best traits and behaviours and can further evolve them, with or without the continued guidance of that leader. A good leader is a good listener, prepared to challenge, and willing to be challenged. There are few things more dangerous to delivering high quality work than an echo chamber or deference to a single perspective. I expect that there will be a diversity of opinions on a team and that my team mates will share opinions directly and openly. This always with the intent of arriving at the best possible resolution under the current circumstances. Once we have arrived at a resolution, debate ends, and we align on that resolution. There will always be at least one appropriate time to review that decision and its outcome and alter course, in the future, such as a Sprint Retrospective. There are no best practices. The idea that certain practices or approaches that must be applied regardless of context, that are unchallengeable by virtue of being “the best”, and are immutable, is a menace. It interferes with teams’ ability to adapt, evolve and grow. We should aim to stay informed and seek out practices that serve us well for a time and a place, and be prepared to replace them as new information, strategies, or techniques emerge.
Calendar appointments of course.
You can reach me during regular working hours via Email
I may not respond immediately. I will before the end of the business day, Eastern Time.
Active: It is important for me to be an active contributor when it comes to the work we have before us. As a leader, I may have competing priorities for my time and I cannot become a blocker. Most often compromising between these two requirements involves me taking on tasks that are identified as valuable but aren’t located on the immediate critical path. One example is that my contribution may primarily involve reviewing Pull Requests or contributing platform and tooling improvements. At other times I have found that am able to contribute as part of a regular product increment.
Adaptable: I will do my best to adapt my leadership and communications style to fit your specific needs or what the situation requires.
One on Ones: I find it easier and more effective to address questions, concerns, obstacles, and feedback in a short cycle. To start I would like to meet one on one once a week for about thirty minutes. As time goes on, we can gauge if we need to meet for longer, or less frequently and change accordingly. If you are reporting to me, I will book a regular, recurring meeting, and make every effort to avoid changing the time or cancelling. You may request a change in time or cancellation if you need to. Please don’t cancel two in a row. It’s my experience that becomes a burdensome timeframe for any follow up or continuity.
Protect the team Alongside Scrum Masters, it’s important that I shield the team from outside distractions and interference. It is also important that I protect us from our own complacency and from overwork, equally.
Quality belongs to the whole team . Measures of quality are useful as part of a definition of done, or acceptance criteria.
Resourceful I strive to be proactive and resourceful. I strongly encourage those traits in all of my team mates as well. Mistakes become problems primarily when we fail to learn from them.
Respectful I make it a point to treat others with the same degree of respect and empathy that I expect from them. I value colleagues who do the same.
No team exists without a customer. That customer may be internal or external, but they are a customer. Any team delivers better results by first understanding the needs and goals of the customer. The better our understanding of who our customer is, and how we can help them, the greater the clarity and shared purpose for each team member. Clarity brings team cohesion and a shared purpose can resolve many problems in teams’ dynamics, often before they emerge. If we know why, what and how become much easier to find.
Teamwork: not only for motivational posters
⚽️ “Team” in this context means between three and ten people working together for a shared outcome. My experience is that teams are most effective when they are composed of all the disciplines directly involved in the achieving that outcome. Typically, this includes UX Designers, Software Developers, DevOps/SRE, Product Owners, and optionally, software testers, software architects.
It is up to the team to collectively decide how much or how little each team member may specialize or “branch out”. I prefer that we approach work with an attitude of “anywhere I am able to contribute effectively, I will”. We are rarely only good at one thing, there’s no reason to limit ourselves by job title.
Co-creating builds trust, it also improves communications, and reduces the overhead associated with hand offs. This applies both to pairing or mob programming and to co-creating across disciplines.
Understand the problem you are solving and why you should solve it . Take the time and the measures required to ensure that you are addressing the right problem, first. Avoid a “Ready, Fire! Aim,” approach to development where a design, a technology, or a framework becomes the solution in search of a problem. Solving the right problem with a suboptimal technological approach is better than delivering a perfect technical solution that solves the wrong problem.
Give people clear goals , a purpose, the right tools to succeed, and get out of their way. Giving team mates freedom, flexibility, and providing stretch goals as required is far more effective than micromanaging them.
Decision making should be collaborative , as much as is reasonable. Decisions should be deferred to the last responsible moment. Combined, these principles significantly improve the quality of decision making by allowing us access to the most complete amount of information available to help arrive at a decision. Yes “responsible” and “reasonable” are both doing a lot of work here. We have brains, and the ability to exercise judgement, let’s use them.
✅ Use time boxes and tie breaking strategies to avoid decision making gridlock within the team.
A corollary to that is collaborative decision making takes practice. For most of us, it’s a learned skill. Sometimes it takes time to get to the point where teams have developed that skill. In cases like that, we may temporarily fall back to a prescriptive decision-making process in order to keep moving forward. ⚠️ In situations where accountability for the decision rests with me individually or primarily. I may make that decision individually. These are exceptions and typically not directly related to the product or its roadmap.
Maximize the amount of work not done. This phrase is taken from the Agile Manifesto. For me it speaks to the need to focus on the task of delivering the most value relative to the effort involved. Techniques to achieve this include
Mutual-trust is required. There is a small number of behaviors that erode my trust in colleagues: withholding important information, avoiding difficult conversations, or treating others with disrespect. If our trust is broken, I will find it difficult for us to continue to work together productively.
Avoid acting with entitlement
, ego or self-importance. We are all part of a team aiming for the same goal. Behaving as if
there is a separate set of rules for you is corrosive to team cohesion, and expensive
because it impairs the team’s ability to collaborate effectively.
Surprises are appropriate for birthday parties, not for work. If something is wrong, going
wrong, or if you have made or found an error that needs my attention, please let me know
ASAP.
I am red/green colourblind. Documents or other media using colour coding alone to convey information can lead to me missing something important, or requiring someone else’s help in order fully grok what I am presented with. In order to keep the overhead low, please provide an additional indicator such as texture or patterns, numbering, or labels when providing information using color. This mild disability occasionally provides me useful lived experience to apply where Inclusive Web or Mobile design considerations are involved.