YOW! September 2021 Recap
Andy Kelk
Andy Kelk of Marketplacer gave a talk about scaling your business and trying to balance pace and rapid reponse with keeping things stable, certain and certified for your customer base. While admitting there is no silver bullet to do this successfully, he did outline the steps taken at Marketplacer and some of the lessons learned along the way.
Security and Compliance
While this is an area typically associated with red tape and piles of paperwork, Kelk stressed that this doesn’t need to be the case. Needing to show compliance to standards for some of their larger customers, Kelk’s team selected ISO-27001 with the reasoning that it outlined what needed to be done to be compliant, but it wasn’t prescriptive about how you implemented your compliance. This allowed the company relative autonomy to put in place processes and controls that were compliant, but didn’t impede delivery. Kelk also noted as their clients got bigger, the collection of supporting evidence to show how compliant the company was started to get more and more important.
Communication
Marketplacer experienced communication challenges that were all to familiar to me; once a small team in a small office where you could turn around and ask a question of the person behind you, now they had to tackle timezones, a dramatically different org structure, and many different teams. Kelk reiterated time and again that communication was not something that would be ever ‘solved’, but rather it would be ‘evolved’ as time went on. They would try something, keep it if it worked, or iterate if it didn’t. This meant initiatives like:
- Conventional commits, so tooling could parse commits from across the company and post into an internal #changelog slack channel for those interested
- A company-wide roadmap that anyone could look at whenever they liked
- A weekly “launch wall” meeting where team reps would talk about what was going live that week
- Combating the lag time between ‘code done’ and ‘launch ready’ through the use of feature flags
This last point in particular was reinforced;
“Separating deploys from releases has become more and more important for our company to be successful.”
Team Growth
As the organisation scales, it’s often tempting to think that adding more people to Engineering will get more done. (Note: this brought much virtual laughter in the conference chat.) This of course is not the case, as you need to manage how those people communicate and operate alongside everyone else, not to mention keep or evolve your team’s culture. Kelk talked about taking a very deliberate approach to this problem, and taking conscious steps to ensure people felt connected to each other, even when pandemics and timezones got in the way.
“Work time isn’t always just about work.”
Referencing Dunbar’s numbers, he explains that they kept their teams small and stable around the size of 5 +/- 2 members to ensure that internal relationships could build and solidify among team members. They were also care to limit the amount of changes made to teams;
“Each time you add or remove someone to a team, you’ve created a new team. And they have to form all those bonds over again.”
Also important is the concept of not so much silo-ing teams, but avoiding placing dependencies and constraints on each other whereever possible;
“We try very hard to have teams work independently where they don’t need to co-ordinate. This means that we need co-ordination at the working group level. Our company-wide roadmap and end of sprint info session also aims to keep everyone up to date with what other teams are doing.We generally have one PM per value stream team. Then there’ll be 2 to 4 engineers in that team. We try and keep people into one team only and not sitting across multiple teams.”
Marketplacer take the approach of “tweaking” teams only once every six months, and even then taking care not to change too much at the one time. Larger, whole-team forming or carving activities are saved for 12 monthly intervals. Kelk reinforced that it’s impossible to be static; your customers aren’t, neither are their demands, and your organisation and team will need to flex over time to adjust to this.
Unsurprisingly, as the team grows, they get more expensive. This makes things like ATO R&D grant submissions really important. At the same time, people hate timesheets - Marketplacer’s solution was to SlackOps this. Nikabot was used for timesheeting directly from Slack, and had the ability to learn and predict people’s patterns over time, removing the annoying copy-and-paste timesheet entries that people found a drudgery to fill out.
Values
Andy spoke about the value of trust in an organisation.
“You must build psychological safety, and engineer trust with your people. Slack channels for example are open by default - we still need a few which are closed off for good reason, but we don’t aim to hide things at a base level.”
Likewise, the value of continuous improvement is important for the organisation to continue prospering. Kelk spoke about the team being encouraged to call out when something they used to do wasn’t working any longer, and to tweak and modify until they got better results. Managers at Marketplacer also, where possible, don’t become decision makers - they instead build autonomous teams and try to “push the decision down”. This has the benefit of not only removing a constraint from the equation, but growing capability in the teams themselves.
Support
Providing people the right support is key to achieving the vision you have for your team. Kelk spoke about supporting his teams’ desires to learn new skills, and in return getting a team that was ready to support each other. He also spoke to the value of moving past primitive numbers when looking at performance;
“The key is to measure people by impact, not the lines of code or the number of commits they write.”
The team had a #shoutouts channel on Slack to thank each other on a job well done or for help received. Importantly, they also had the tooling that made them the most productive.
“Look, just get the right tool for the job - and pay for it. It’s worth it. We try and consolidate on tooling where it makes sense, but not religiously and not for the sake of it. It’s not worth burning people’s productivity.”
Stability
Kelk finished up his talk by reflecting on the nature of change and needing to provide a steady hand through it. He spoke about trying not to overload his teams with change, in an effort not to bring about fatigue. Immutable teams were an important factor in providing the stability needed to work productively and build a good culture; but sometimes things did need to change and it was important that people understood why.
In return, during talks with their manager people would get to nominate which teams they’d like to work in, in priority order. So when changes did need to be made in future, leaders could try to balance people’s development needs with what the company was looking to switch up.
Overall, I really enjoyed Andy’s talk. I’ve had to wrestle with some of these problems myself during a ‘scale up’ phase, and it’s hard to convey how difficult some of this stuff is. As he said to begin with, there is no silver bullet here - but there was enough solid, pragmatic advice steeped in real world experience in this talk to make it really worthwhile.