This continues the story from “Managerless Engineering: The First Month…”
With the teams sprinting, two freshly-minted Product Owners guiding them through User Stories, and weekly all-hands meetings where every team Demoed to the whole company, things were moving fast.
The big learning this month was about 1-to-1’s
Over the years I’d come to respect 1-to-1’s as a core part of running a high-functioning, fast-moving organization. I’d also often experienced their absence — from the managers that could only spare time to see me once every two months, to the ones that organized a meeting every week but cancelled three in every four. This time round, given the successes of our person-to-person coaching when launching the new structure, I looked around and decided to create a culture of pro-active, highly-valued, 1-to-1s for everyone.
And, with no line-managers, I felt this was the leanest, cleanest way to provide the missing communication channels that employees usually need to feel safe, respected, valued, and supported. We’d done much to empower teams, but that mustn’t come at the cost of abandoning individuals.
Before the re-org, I’d started with one person receiving 1-to-1 meetings. After a good first meeting, and his positive comments, I rolled it out to a few volunteers from his team (he was able to explain what he’d got out of it and help people self-select for it). After switching org structure, I switched my 1:1 approach from informal to methodical: a spreadsheet of every staff member, and columns for who they were receiving 1-to-1s from, how often, and what the confirmed dates were of last and next meetings.
After a few experiments with different people, we settled on this format:
- Each person gets a 1-to-1 every 2 weeks
- 1-to-1s are ultra high-priority: you do not cancel, postpone, or reschedule except for minor changes (a 1 hr shift in time, for instance)
- The meeting is led and owned by the recipient (the meeting is arranged by them, if rescheduling has to happen it comes from them, etc)
- (3 months later: also added, based on observation: “for problems with non-obvious solutions, start with revisiting the shared Company Cultural Values”, because that kept happening and proving valuable time and time again)
…but the facilitator has four topics they have to make sure are covered by the end of the meeting:
- How do you feel things are going right now? (← this is most of the meeting)
- What Continuing Professional Development (CPD) are you doing?
- What are you going to do before next meeting? (← this is part of our culture: don’t wait for others to do things: if you see a problem, or an opportunity, ask what you can do to kickstart the fix or project)
- What CPD will you do before next meeting?
Lesson 1: Plan for 1-to-1s explicitly
1-to-1s are famous for startups, “talking the talk but not walking the walk”. They are hugely expensive in time — especially Founders’ time. But failing to do them is a terrible mistake. In a managerless-environment, it’s even worse: employees need it for their own personal growth and productivity, and founders need it for honest feedback and understanding of what’s happening in the company they created but where they’re constantly decentralising, delegating, devolving responsibilities as it grows.
Lesson 2: Autonomous culture is so novel it needs dedicated onboarding
Culture-onboarding is critical to our success. Our existing staff had 6 hours of discussion of our cultural values over the course of 4 weeks of all-hands meetings; new joiners had none (although I made sure we filmed the cultural meetings, so new joiners even a year later could go back and see the original explanation of what were were trying to do and why). We were going to do Culture as part of the individual’s first-day onboarding, but by the time we were ready to do that, we had a backlog of 8 people, so we did it in a workshop/roundtable format instead. This worked brilliantly, and became our new process going forwards: new joiners spend 1–3 weeks at the company experiencing our reality, and then a cohort of recent joiners have a shared culture-onboarding session. Like doing an MBA after having real-world experience, this gives our new staff reference points for all the cultural goals, and concrete experiences to share and discuss.
Lesson 3: Product Owners naturally become Project Managers/Team Leads
Product Owners become the main point-of-contact for the new org-structure. I fought long and hard to prevent our PO’s become line-managers-by-stealth, or PM’s (see below), but it’s almost impossible. As a primary driver of thinking (co-writing and reviewing User Stories) and commitment (asking teams to commit each sprint), they end up being the people that individuals often turn to for judgement calls on uncertain issues.
Lesson 4: Autonomy is easier to embrace for people who are changing company
New joiners adopt autonomy much faster than old hands. I thought that our long-term staff — who’d lived and breathed the prehistory of our culture, and shaped it — would be the most enthusiastic adopters. In most areas, this was true. But when it came to standing up and taking ownership of things, of never asking permission but instead acting and suggesting … the new joiners had no fear. The existing staff needed a few weeks of watching people stand up and do things they didn’t believe they had permission for — and watching how positively the rest of the company, and the Founders, reacted — before starting to do it themselves.
Lesson 5: Autonomy is Contagious
While we were finding our feet with the new structure in our Engineering teams, we were slow in describing the changes to the rest of the company (Sales, Marketing, Admin, HR, etc). But they saw. And they wanted it too. We deliberately involved them in the public artifacts — especially the Sprint Demos — and encouraged them to ask naive questions (lead by the Founders, asking “idiot questions” in each Sprint demo, helping the Engineering teams re-pitch their stories to non-tech audience, and empowering non-tech people to feel confident to ask such questions themselves instead of languishing in silence). But that cannot account for how rapidly and eagerly they raced to adopt the ideas themselves: something this good is so attractive that even doing a small seed of it, and getting it even half-right, will trigger adoption across your organization.
Complex design is hard; simple design is harder
I want to highlight something here: our implementation of these concepts appeared to sprout overnight, and be iterated heavily daily and weekly. We were highly uncertain at all points, constantly afraid that we didn’t know how to do this best, bailing water in a leaking boat just fast enough to keep afloat. And it worked!
But. This hides the months of pre-preparation that went into it. The operational side was lightly planned — we expected to adapt on the fly — but the cultural and emotional sides were heavily explored and mapped-out. I have seen many, many organizations attempt autonomy-granting structures and mangle them, then crash and burn and blame the autonomy. From experiences both happy and bitter I had a mental list of warning signs that we were going off-track, and of success-signs to look for in people and teams to know that they had internalized the current part and were ready for the next stage.
Like ducks on a lake: above the surface we appeared to glide along, but only because under the water our legs had been paddling madly for ages.
PO vs PM
A recurring challenge is the difference between a Product Owner and a Product Manager. I found a wide variety of interpretations here both inside and outside the company, but I’ve tried to stick to what I believe are the most well-known interpretations.
Product Manager: “The CEO of the product” — as Google used to say: our Product Managers would be CEOs of the company if they worked anywhere else. These people have control, lots of it. Power. Budget. Authority. They are also the vision-holder for a product — but they are so much more. They take holistic overall management of the product, everything from design through delivery to commercial strategy and pricing.
Product Owner: “Empower the team to make the right thing” — Product Owners don’t have control. They don’t decide. They work with groups of stakeholders (including one or more vision-holders! With multiple, the Product Owner has to resolve the differences and merge it into a single vision). Their job is to support the team they work with, providing that team with clear and comprehensible wishlists from customers, in a way that the team can most efficiently and effectively work with. One way of putting this: the Product Owner is not apart from the team, they are simply one of the team-members (equal with all the others) who has a specialised role: preparing and updating the team’s understanding of what the team is working on next.
Challenges and Weaknesses
Current things we’re wrestling with, and have run multiple experiments with:
Accountability: demos are great, but don’t inherently hold teams accountable. If teams don’t (yet) understand the need to hold themselves and each other accountable, you can veer off into Research territory: no delivery, no schedule, no customer-visible focus.
Dissolvable teams: We aim to have teams grow and shrink sprint-to-sprint, but that isn’t happening yet. How can it happen? How do people know other teams are ready for them? We had one big kickoff meeting (the Emoji Meeting) for teams to self-organize, but were too afraid to repeat it sprint-to-sprint because it’s expensive to have so many people tied up for that time each week.
How small is too small: in our first attempt, we had teams of 2–5 people, but half of them were 2 people or less. One team was only 1 person! As a former Scrum Master, this alarmed me — you don’t get the benefits of teaming, and you pay the costs of bureaucracy and process-overhead.
My Current thinking …
… On Accountability, teams have started self-declaring their failed sprints. Other teams are adopting a shared slide in their Demos that summarises “This sprint’s goal; How that feeds into the team’s long-term goals; How we think you should measure our success/failure to that goal during this sprint; What we think we should do next sprint”. Some teams are experimenting with voluntary Sprint Reviews (in detail, with stakeholders) to complement their Sprint Demos (light, show-don’t-tell, with all staff).
… On team forming and re-forming, we have two teams coming towards natural downsizing (or even dissolution) points, with their projects achieved, so we’ve scheduled a new Emoji meeting for a few weeks time (just after the next release). Individuals have proposed pre-completion “Mission Review Workshops” (like a Sprint Review, but for the overall project — giving a chance to double-check that stakeholders needs are about to be fulfilled, a few sprints in advance, giving time to course-correct), and created a weekly Pitch Event for anyone in company to pitch ideas for new teams and why they are urgent enough to form now.
… On minimum-team-size, during end-of-Sprint demos, our teams-of-two have stood up and highlighted (and shared) their own experiences of the fixed-overhead costs of being a team, and how it makes it very hard to achieve significant progress within a single Sprint. Discussion here is ongoing — two teams failed their Sprint Goals mostly because of being understaffed, so it’s front of their minds and the rest of ours. The POs have also agreed that a slightly longer sprint — 2 weeks instead of 1 (or even longer) — would be preferable for the kind of work we do, once the teams have finished the big-change iterations on structure and feel confident to go longer in-between checks and reporting.
Continued in part 3: “Towards Tribes: Month 3”
