Building a team that didn't need me
- Company
- Barrows
- Year
- 2018-2020
- Role
- Product ownership
The software team at Barrows was brand new when I joined. Not the people, though. Some of the developers had been there for years and others had just graduated, but a new scrum master had only recently pulled them together from separate projects and handed them one backlog, along with two systems that didn't talk to each other. One ran manufacturing. The other went out into the field with the people auditing and installing displays in stores. Our job was to turn those two into one.
Updates went live over FTP. There was no Git, no code reviews and no pipeline, so I could have written the rulebook myself. Instead, I asked the team what good looked like to them and let them go and find out. They read, they took ideas home from dev conferences, and they came back with a plan of their own. My part was making room for it on the roadmap and helping steer it all the way into production. By 2020 they were reviewing each other's code and shipping through a pipeline they had designed. I never did write that rulebook.
Then one day the servers went down. The real ones, in the cold room, with the blinking lights. For two days nobody could write a line of code, so I put pens and printed phone templates on a table, and everyone sketched the next release, our QA engineer and our junior developer included. Then we mapped it end to end on sticky notes. That map became our plan, our progress report and the thing stakeholders could actually react to. When we tested it with field staff in a sandbox, it showed us we'd need to support the old process and the new one side by side. Finding that in a pilot, and not in a nationwide rollout, saved everyone a lot of pain.
People build better when they've helped decide what to build. I gave that team the context once, and then I trusted them with it. I'm still in touch with them, and they're still building.