This is the Engineering Culture Podcast, from the people behind InfoQ.com and the QCon conferences.
In this podcast, Shane Hastie, Lead Editor for Culture & Methods, spoke to Travis Kimmel of Gitprime about the challenges of being an engineering manager, the value of metrics and how to use them wisely.
Key Takeaways
- There is lots of information about the “stuff” of engineering, but very little on the human processes of engineering
- Without a data layer that gives insight into the process, the manager needs to interrupt the flow of work to understand what’s happening
- The difficulty in running an engineering team is ensuring that the impulse to build is aligned with the overall business goals
- The state of nature for engineering is a group of people building interesting things that make sense from a business value perspective – if any of these point stops being true then dysfunction creeps in
- The data generated by a team should be consumed by the manager of that team and they use it to tell the story of how the team is doing to others
Subscribe on:
Show Notes
- 00:25 Introduction
- 01:14 Wiring up and measuring the engineering process
- 01:24 There is lots of information about the “stuff” of engineering, but very little on the process of building products
- 01:40 This absence of data makes it more difficult to be a good engineering manager
- 01:52 Without a data layer that gives insight into the process the manager needs to interrupt the flow of work to understand what’s happening
- 02:13 The desire to build a set of systems to automate the data gathering and avoid becoming a bottleneck for the engineers
- 02:32 The most value that the engineering manager can provide is knowing when to weigh in on issues that are real blockers for the team
- 02:54 Building products to automate the data gathering and making it available to all the layers of leadership that need it
- 03:15 The state of nature for engineers is productivity, this is very different to many other disciplines
- 03:42 Things that motivate some other professions can be demotivational for engineers
- 03:56 The challenges for engineering managers are around ensuring there is a clear indication of what needs to be built
- 04:14 Ensuring there is a shared understanding of how the group of engineers move together to achieve a common goal around building a product which can be sold
- 04:25 Communication is incredibly important in this context
- 04:38 The challenges in engineering are not about generating more productivity, it’s about removing the things that get in the way of the naturally productive state
- 05:06 An important aspect is how do we communicate the productivity state to stakeholders outside of engineering
- 05:20 Discussing how engineering managers need to argue for funding using robust metrics
- 06:08 Examples of how miscommunication happens when discussing engineering work with non-technical stakeholders
- 07:03 Being busy does not necessarily mean generating value
- 07:12 Examples of how the default state of engineers is to build awesome things
- 07:32 The difficulty in running an engineering team is ensuring that the impulse to build is aligned with the overall business goals
- 07:47 Explaining the “green button” issue and how communication breakdowns happen
- 09:05 The difference in perception about efficiency and effectiveness between engineering teams and other groups
- 09:31 Productivity is about moving towards a shared goal together, not about typing faster
- 10:08 Joking about where engineering managers come from – pick the most extraverted person in the group and make them the manager without any training in management skills
- 10:47 It is better for a manager in an engineering team to have a technical background
- 10:58 The lack of clarity to many new engineering managers about why the various management practices are in place, so they often do them badly
- 11:15 Teach new managers why management roles exist and what’s important in the role, what’s the goal of the role
- 11:29 The goal of a manager in engineering or other creative environments is to create a pocket of time that engineers can work in without being interrupted and distracted
- 11:43 The manager is the sacrificial engineer – they go to meetings so that the others don’t have to
- 12:03 The manager is also responsible for ensuring what is being built matches the business goals
- 12:13 Often a dysfunctional team comes about because the manager as sacrificial engineer pattern is not being followed
- 12:21 What happens for many newly promoted managers
- 12:44 The managers' responsibility to protect the productive time of the rest of the team
- 13:03 An example of how the engineering manager fills in the gaps in communication for the team
- 13:39 Where managers are not equipped to do their job then dysfunctional teams are the result
- 14:16 Levers the engineering manager has at their disposal to help teams get aligned around business goals
- 14:27 If engineers are not able to spend most of their time working on the codebase it is usually an indication of a management process failure
- 14:52 Engineers want to solve problems and are helpful by nature, often to their own detriment and to the detriment of focused work
- 15:03 Examples of how distractions happen
- 15:24 The state of nature for engineering is a group of people building interesting things that make sense from a business value perspective – if any of these points stops being true then dysfunction creeps in
- 15:48 Explaining how in an engineering sense a 2:30 pm meeting is a death-nell for the entire afternoon’s productivity
- 16:09 Engineering work happens in large, uninterrupted blocks of time that enable a flow state – a typically half-day at a time
- 16:28 Measure how many uninterrupted half-day blocks engineering teams have available to them in an average week. In dysfunctional teams, this could be as low as 2 or 3
- 16:57 When interrupting these blocks of time, you decrease productivity by preventing flow from happening
- 17:06 Most organizations don’t measure available time and these interrupted time blocks are invisible – make it visible
- 17:27 Identifying good and bad metrics
- 17:32 Reductionism is never good, and lines of code are worse than useless as a metric
- 17:49 Counting how many big blocks of uninterrupted time the team has available is a positive measure of a manager’s effectiveness
- 18:07 How long does it take from a pull request to a customer experiencing the changed product?
- 18:30 Similar to accounts receivable aging, there is a concept of aging of engineering deliverables – how long does it take from the engineer completing a task to the new/changed capability being in the hands of a customer
- 18:42 Measure the lag in the deployment flow and work on the bottlenecks
- 19:13 Beware the seductive temptation to count the easy things
- 19:24 Reductionism as a way to view creative work is toxic
- 19:37 The metaphor of a pilot reading an altimeter without understanding the terrain they are flying over
- 20:04 The importance of context for any set of metrics
- 20:09 Examples of how context can be given with the data and the value of being able to drill into the detail to understand the background to a data point
- 21:00 Exploring the history of different processes
- 21:29 The trend towards adapting faster and faster to feedback and learning
- 21:34 The analogy to raising children
- 21:57 If your team has a process that is working for them, don’t change it for the sake of change
- 22:11 Adopting metrics and measurement to create a feedback loop to learn from experimenting with different processes
- 22:42 If you can quantify the results of a process change it becomes possible to explain the value of improves processes
- 23:13 Preventing the weaponization of metrics
- 23:32 Allow teams to customize the output of a system of measurement to their culture
- 23:42 An example of this customization with a “CEO Seat” which shows aggregate measures and prevents drilling into specific details
- 24:48 The management data presented needs to be designed in such a way that it is consumed by management within the engineering department
- 25:13 How other industries and areas of the organization face the same challenges (eg sales)
- 25:28 The data generated by a team should be consumed by the manager of that team and they use it to tell the story of how the team is doing to others
- 25:42 Most engineering managers want to do the best possible for their teams
- 25:56 An example of how a manager can use data to make an effective case for a new build tool for their team
- 26:35 Exploring psychological safety in the workplace
- 26:45 Psychological safety is not about happiness, it’s about risk-taking behavior
- 27:13 Daniel Pink’s work on motivation in creative work
- 27:42 The goal of a manager is to create a space of safety where engineers can work
- 27:57 The correct answer to “how does the organization treat failure” should be “with a lot of kindness”
- 28:13 Use the metrics around how we build things to debug the failure, make it cool to look at failure
- 28:32 Explaining how that could be done with an example
Mentioned:
- Gitprime
- Google – Psychological Safety
- Daniel Pink – Drive
- Travis on Twitter
- Gitprime Newsletter
