BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Podcasts Travis Kimmel on What Makes a Good Engineering Manager

Travis Kimmel on What Makes a Good Engineering Manager

Bookmarks

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

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:

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

BT