Articles by Rod Begbie
- Engineering Management Anti-Patterns
Rod names and shares some anti-patterns learned from his own experience as an engineering manager: the cloner, the decider, the buddy, the asshole, the joker, the wolf-cryer and the shit umbrella.
- The Geometry of Software Teams
Rod provides a set of tools to structure engineering teams and increase effectiveness, productivity & happiness: • The parameters of software teams • Balancing experience levels across software teams • The risks of solo work • The different forms of ownership: technical and process
- Being right is only half the battle
In this talk, Rod explains how to capitalize on your interpersonal connections within your workplace to drive consensus, to optimize your time and efforts while selling your ideas to others, to reduce surprise to help you achieve your goals, and to build a strategy that can be bought into by other leaders and executed on by your team without you having to micromanage the process.
- Hypothesis-driven development
Hypothesis-driven development is a scientific approach to problem solving that involves defining and stating hypotheses at the beginning of design, and measuring the success through a process of incremental, phased development. A good hypothesis is a statement about what you believe to be true today, and should contain neither the words 'if' nor 'then'. Predictions are used to define the smallest possible piece of work that could be built and produce a learning. This approach allows teams to stay focused on projects that will move their product to deliver their business goals, without over-investing in work that doesn't move the needle. It also encourages more-junior engineers to confidently throw out suggestions, as the discussion is focused on the simplest ways to test the hypotheses. This approach has been used successfully by product growth teams, but can be applied to different engineering problems.
- Estimating your way to success
Rod discusses four reasons why estimation is so important, and shares some tactical tips around estimate granularity, including bugs in sprints, retrospectives and more. 1. Estimation forces us to think about what we’re going to do before we start writing code 2. Estimation enables meaningful discussion between engineers pre-development 3. Estimation is valuable input for informed product scoping 4. Estimation gathers data we can measure against at the end of the project