Internet flâneur · Built Pagecord
Posts tagged with leadership
So impressed with Matthew Prince, Cloudflare CEO. Read his response on Hacker News to the question of how they could get a post-mortem out so quickly. Leadership++.
The full post-mortem is worth a read, and I'd also recommend listening to Matthew's recent interview with Amol Rajan on the Radical podcast.
I’ll be the first to admit that some progression frameworks are lacking in substance, often speaking in banal generics and lacking tangible examples. I know this because I’ve written plenty of regrettable howlers.
Without a progression framework, or at the very least a list of expectations for a given role, you’re hanging people out to dry. You’re opening up performance reviews to all those wretched cognitive biases, which is why something is better than nothing but a coherent progression framework is the current gold standard you should be aiming for.
Virtually all tech companies will have have a career ladder that goes something like junior → mid-level → senior → very senior → super-senior. A progression framework describes what is expected on each of these rungs, across multiple dimensions such as skill, communication, engagement, leadership, and so on. It’s called a progression framework because it will make clear how each expectation progresses from one level to the next, as this seminal ‘rope analogy’ example from Radford demonstrates:
When people are hired they’ll be taken through interviews and technical challenges and an assessment will be made on where they sit on this ladder. On this, where things are not clear it’s better to match people against the lower level. This sounds tight-fisted, but acknowledging a mistake and promoting a mid-level hire to senior after a couple of months in the role is easy. You’re doing nobody any favours by hiring them into an overly senior role just because it’s the role which matches the salary they want. This won’t end well, believe. But I digress…
The same assessment is made for each person during their (annual, bi-annual, whatever) performance review, which will be far more accurate than the initial hiring assessment because you’ll have a wealth of direct on-the-job evidence to draw from by then. Making a fair assessment is where a progression framework comes in. A progression framework allows you to articulate, in depth, what it means to be a mid, senior or principal engineer at your company. It’s crucial to developing someone in their career, which keeps people more engaged and less likely to go looking elsewhere for a new challenge. People need to know where they’re at, and what they need to do in order to get to the next level. How can you do this without some sort of benchmark? Spoiler: you can’t.
Introducing a progression framework will be a challenge. You’ll hear cries of pigeon-holing and box-ticking, which isn’t actually unreasonable – it's usually just a misunderstanding. There’s an inherent fear of receiving critical feedback if you’re not used to it, but feedback is essential to improving performance. Just ask anyone with a personal trainer. At some micro level, you are putting someone in a box called senior, or staff, or whatever. You’re making an assessment and you’re calibrating people against others. This sounds rather awful, mainly because of the unpleasant and dehumanised HR language ("assessment", "calibration", "review"). I’ve been guilty of this, of course, but with a bit of imagination you can avoid the jargon.
At smaller companies, especially ones like 37signals, creatives (by which I mean programmers and designers) are working so closely that someone’s skill level and overall contributions will be obvious. You can see what they’re producing and the impact they’re having day after day, so why do you need a new and irritating "box-ticking exercise"? It’s a good question, but manager-lite arrangements with highly technical supervision are just as open to bias as more "professional manager" setups. Recency bias after shipping that popular feature. Primacy bias because you still remember their first ever project which they absolutely nailed. Halo effect bias because that person’s performance peaks are so fucking high despite the fact their day-to-day performance is a flat calm, even atrophied, most of the time.
To earn trust in the framework, you have to be able to demonstrate its value to everyone it affects. In time, it’s likely you’ll get buy in from most, if not all, because people will see it working for them and for their peers. If the worst happens and the whole thing is an abject failure, don’t hesitate to admit it. Throw it away and reset. Lean on your teams to find a better path forward.
If you’re not using a progression framework right now, you should create one. If you are using a framework, be sure to reassess it every couple of years. Always get input from those at the front-line. There are plenty of examples out there to gain inspiration from (or outright steal), but remember it’s always a time-consuming exercise, but one with a high return on effort. Don't scrimp, just take your time.
People often moan about meetings, often for good reason. Here's how I deal with them.
I read an article recently about how GitLab automates engineering management. My interest was piqued by the title but watching the accompanying video left me wide-eyed. Using Google Docs, the script editor and copy/pasting long alphanumeric IDs doesn't strike me as particularly fun or efficient. It seems like a very high barrier to entry, but I guess it works for them 🤷.
I'm not getting involved in the meetings versus no meetings culture war (you're both right), but on the back of the GitLab article I thought I would write about a way to keep track of the meetings you run.
Unless you work at Gumroad, I'm assuming that you participate in some sort of meeting at some point each week. At the very least I would recommend having 1-1s with your manager/reports weekly (or thereabouts... but I do recommend weekly). Meetings work best when there's an agenda prepared in advance (at least one working day or more) so that attendees can prepare themselves, and also so any reference materials that might be relevant can be shared with time for people to read it. Depending on the type of meeting (e.g. incident review), you might also want to take minutes, list attendees and note down action points.
Using a good tool like Notion (which is my current preference) for these agendas can make your life a lot easier. Here's one way to do it.
Notion is a wiki so works hierarchically. Create a new page to act as the root for all your meeting notes (in reality you'll likely have multiple roots) then embed a database into this page. Here's a contrived example:
Having all these pages/notes in a database is brilliant because as the number of pages grows, you can add filters and sorts and different views. It's really powerful, but the UX is kept reasonably simple.
The power of using Notion for this is that you can pre-define templates, which are essentially different page layouts. Once you've defined a template, you can create a new meeting agenda from it in a single click, and all the annoying boilerplate is pre-populated for you. No copy/pasting required.
Here's what a 1-1 template might look like:
Templates can be used for weekly leadership meetings, team retrospectives, and they are extremely useful for incident response – both living incident docs as well as post-incident review meetings. When things are on fire, you want to create an incident doc without thinking about it at all – you certainly don't want to resort to copy and pasting Google Docs.
(Note: I've included some example templates at the bottom of this article.)
In many ways this is less about the tool and more about the process. A good tool (like Notion, but there are plenty of others!) can/should be intuitive and reduce cognitive load from repetitive tasks.
Regarding the process of meetings, what I've learned over the years is that meetings (when you absolutely must have them) should:
I've found these to be really helpful guidelines over the years, but I've also found it very difficult to enact culturally however much 'leading by example' you try to do. Old habits die hard, and you have to over-communicate this stuff tirelessly. Thankfully, if you spend time reducing your meeting overhead as much as possible this won't be a massive problem.
Links to my Notion templates:
I recently announced my decision to leave FreeAgent, the company I co-founded in 2007. It's been a difficult decision to make as I love FreeAgent dearly – I’m part of the furniture almost – but it’s the right time for me to hang up my well-worn CTO boots. I wanted to write a few words for posterity, so here are some of my memories from our rollercoaster journey.
5,387 days ago (19th Feb 2007), having recently quit a contract where I was completely downhearted working on an unfathomable credit derivatives product at RBS on Bishopsgate in London, and with a bookkeeping web app called One Man Band running through my mind, I contacted Ed after seeing a message he'd posted on the back channel of the Future of Web Apps conference which we were both attending. The message said something along the lines of "Come and talk to me about FreeAgent Central: Solo Simplified" and there was a landing page at freeagentcentral.co.uk with hot air balloons. I was both deflated (unlike the balloons) – that was my idea dammit – yet excited, because Ed had actually produced something that looked great, was written in Ruby on Rails, and it sounded like there might be a chance to get involved.
We met in the basement of a conference centre in South Kensington and I had a look at the "FreeAgent Central" prototype which looked pretty good. It had animated sliding help menus (RIP) and everything. I was impressed! We had a good chat, I said I was up for getting involved, and that was that. What followed was a blast.
I'd done some interesting work before: launched games, PC desktop publishing products, internet radio stations. I was already working for myself since I quit my full time job in 2005, set up a limited company and got a 6-month contract in a bank. So there I was, wearing a shirt, trousers and polished shoes, getting sardined on the Northern Line to Moorgate each morning but at least I was sort of a bit more charge of my own destiny.
My long term plan at that point, or rather what was in the back of my mind (I had no plan), wasn't to be a full-time contractor for the next 20 years (a sensible and lucrative option which was encouraged by my accountant at the time). The idea was to milk a couple of City contracts for as much money as possible, live reasonably frugally and build up some savings in order to try and make a living actually working for myself on my own product. Inspired by "Web 2.0" companies such as Basecamp, Flickr, De.licio.us, this lifestyle felt in reach. I did some client web design on the side but quickly discovered that this was hard work. It was frustrating dealing with nitpicking clients and the general return on investment was poor. I tried the software agency model of pitching to businesses to build web apps, but I was terrible at it.
Meeting Ed (and subsequently Roan) changed this. FreeAgent was solving a problem that I wanted to try and solve, that I actually had a bunch of experience with, using technology that I was eager to learn. It was a classic case of right place, right time.
I was lucky enough to have a decent amount of savings in my limited company so, newly liberated, I started working on FreeAgent every day from our flat in Kennington (ok, Walworth). Ed was still doing some ad hoc consultancy and Roan was still full time in the day job and working evenings at this point, so we used Basecamp to plan work with the occasional Skype call to make things feel a bit more real.
At this time the app had some core functionality and it was well-tested (following The Rails Way). It was my job to add a bunch of missing functionality, polish things and get the product into public beta and ultimately launched, which we planned for later that summer. I loved it! As well as coding and sorting out basic infrastructure (this was 'pre-cloud'), I started networking (friends, acquaintances, local freelancers from meetups I attended) to talk up the product and to get early feedback. There was definitely interest, but general excitement levels were far lower than my own. We released features weekly (we hadn't yet learned the lessons of continuous delivery!) accompanied by cheese-themed blog posts. During the summer we came to an arrangement to allow me to keep working full time until the end of the year, with Ed and Roan continuing with the day jobs.
By the time September rolled around, we officially launched 🚀
The product came with a 30-day free trial which gave me four weeks from launch day to implement a payment system (it literally took this long – now you can do it in approximately four minutes using Stripe) that would allow the $millions to start flowing into our company bank account so we could get the Ferrari's on order. Bring it!
In the first week we got 1 paying customer. £24.
Over the next month or two we started to see a few dozen customers arrive, but it was pretty clear we wouldn't be setting up payroll any time soon. We had zero budget. By this time all three of us had new babies arrive at home, so with no money coming in I was forced to go back to my former employer who kindly offered me a 6-month contract (I think it might have been 3 days/week). We managed to keep on improving the product but it was definitely slower going. Ed focused on sales with some dev on the side, Roan and I focused on developing more features for the app. All of us handled customer support, networking, tweeting, spreading the word. Building a company is, for the majority of entrepreneurs, a hard slog and a long, grinding road. It certainly was for us, but we weren't being ground down – we were still really up for it and believed in the mission.
Towards the end of 2008, Christoph Janz got in touch with Ed after seeing us mentioned in a TechCrunch article we probably badgered Mike Butcher to write. Christoph is a legend and he introduced us to another legend, Robin Klein. Between them, we secured our first investment of around £200k along with another £50-100k or so from friends and smaller angels. This is not a lot by today's standards (I currently see pre-seed - never mind seed - investments of £800k+ 🤯) but enough for us to accelerate things. Doing more with less has been a recurring theme for FreeAgent, and we got pretty good at it.
We hired a sales person on contract, focused on accountancy practices as a new channel and started to see some early success. We had about 1,500 customers in total. Ed was busy pitching to investors and an early lead with a Scottish VC led to an introduction to IRIS, the UK accounting software goliaths. IRIS ended up investing £800k with an exclusive (for a while) deal to sell FreeAgent (co-branded as IRIS OpenBooks) to their accountancy practice clients. We finally had some cash and could start paying ourselves more than £500/mo. It only took about 3 years. We were off!
Although we'd been a remote company for 3 years, the plan was always to get an office in Edinburgh whenever we had the funds to do so. This was a big deal for me and my family as we’d been in London for a decade and had friends and family there. Edinburgh seemed a long way away (it is) but the opportunity to get an office and hire staff was a big one, and I felt that I needed to be there. Things were getting real. Looking back, we probably could have stayed in London and I could have commuted, but that would have been detrimental to family life and, frankly, London life in a small 2-bed with two children was getting tricker and we couldn’t afford to move somewhere bigger. There was also a murder a few yards from our flat towards the end of 2009, so getting out of Walworth to go, well, anywhere, seemed like a pretty good idea. Edinburgh it was!
Our first official office was on Miller Crescent in Morningside which we'd rented for a few months in 2009 (being in London, I only popped in once). Following the IRIS investment, we upgraded and moved across the road to a shared, ant-filled former prison/office on Canaan Lane where we lived for the next couple of years, gradually taking it over and expanding into the neighbouring office (the "dev pit") when our engineering team got to about 7 or 8 people. They were happy days!
By 2011 we had about 6,000 customers and growth was being fuelled by a deal which saw FreeAgent (and a few other SaaS products, and ultimately Sage and QuickBooks I think felt left out) in a package offered to new Barclays Bank business customers. We took more investment from SM Trust in 2011 and moved to our first proper office, complete with fancy fit out, on Torphichen Street. I loved that office! The company was around 30 people by this stage, the IRIS deal was going reasonably well and we started to establish ourselves as one of the main players in the UK. I remember fundraising (for Ed) being a constant battle. We raised money, hired people, added features, grew the customer base... rinse and repeat. We were never profitable, it was always about the next runway.
The next fundraising effort was probably the oddest. The founders of Groupon – Brad Keywell and Eric Lefkofsky – had a startup accelerator called Lightbank in Chicago. They were interested in FreeAgent and there was an opportunity for them to invest which we felt could open doors to getting FreeAgent more established in the USA. We had already made an international version ("FreeAgent Universal") which had a bit of traction despite zero marketing effort, so imagine what we could achieve with a farm of salespeople in a Groupon call centre bringing in leads 24 hours a day? Caribbean islands and private jets ahoy!
This is what was in my naive head at the time, so we flew to Chicago for 36 hours, barely sleeping, and I forgot to buy travel insurance so I had to live with the fear of my general clumsiness resulting in bankruptcy-inducing hospital bills. I got away with it.
The Lightbank deal on the table involved a modest cash investment but also involved acquiring a company, 60mo – a financial forecasting app. To be fair last thing we needed was to acquire a company that used different tech and was based in a city 3700 miles away, but we went ahead with it anyway. We were young and needed the money, but we felt getting Lightbank on board would allow us to kickstart our presence in the US (we even set up FreeAgent, Inc. – a Delaware corporation – around this time). Lightbank obviously wanted an exit for their investment in 60mo and the FreeAgent deal was a tidy way for them to achieve this. We made the most of it – the 60mo founders came on board and helped us build a specific US version of FreeAgent as well as our first mobile web offering, but we ended up parting ways a couple of years later. I felt terrible about this, still do, and it was definitely one of the low points.
The following years took a similar path with customer growth being good, the product constantly getting better and investment being a constant battle. In 2013, with customer numbers over 30,000, we received an acquisition offer which went down to the wire but failed because we demanded (purposefully, sort of) too much. It was pretty exciting and something of an adrenaline rush that made the daily grind of hiring, building features, arguments about prioritisation, people issues and so on disappear for a brief period. Looking back, that acquisition would have been a better outcome financially but it was the right decision at the time. I remember being really up for it, not just because of a cash bonanza but I thought there was potential for a larger impact. At some level (like most businesses) we always struggled with not having enough resource (cash, people, time) and this deal had the potential to change all that, but on the flip side it could equally have been a disaster. Things happen (or don't) for a reason.
Hot on the heels of M&A term sheet drama, we had another potentially big private equity investment which was equally exciting but ultimately didn't work out, so we ended up taking on convertible debt, then some venture debt. Amazingly there were still some fundraising techniques we hadn't yet tried, so in 2015 we ran a crowdfunding campaign which was a total slog, but we got there in the end and raised £1m from hundreds of FreeAgent customers. Thank you! 🙏 We moved to a larger office – our amazing current abode – and no doubt starting thinking about the next fundraising round.
In 2016 we took part in a pitch to RBS/NatWest for a co-branded pilot they wanted to run with an accounting platform. We were thrilled to be selected as their preferred product. We had 50,000 customers and started working with the bank to get some of their customers onboard, and to develop direct automated bank feeds to make the integration feel really slick (automated bank feeds were still a problem at this stage, pre-Open Banking).
At the same time something else was taking shape – we had planned to take the company public on AIM. This was the largest (and most expensive) fundraising we'd done. We'd see great PR, a chunky cash injection and could (in theory) raise capital more easily in the future. An IPO would also be the 'liquidity event' that would allow our early investors, as well as our longer-standing staff who had options, to finally cash out (no such luck for the founders though as it turned out secondaries are frowned upon in the City). Our numbers looked pretty good and the merchant bankers were happy! An enormous amount of work followed over many months, mainly by Ed and Kath, our CFO at the time – I just had to deal with the tech due diligence which I'd been subjected to several times before.
On 16 Nov 2016 we 'rang the bell' (pressed a fake button) in the grand atrium of the London Stock Exchange. Y'all were free to buy shares in FREE! 84p each. Bargain!
We knew it could be tough on the public markets. If you consistently met your projections (and didn't sandbag) you would be rewarded with a buoyant share price. If you failed, you'd be punished and see the share price crash through the floor. This seems pretty brutal because it is. We had the common 'honeymoon' period where the share price grew 50% or more, but after a while it was hovering several points below our IPO price despite growth being pretty good and our financial projections being fairly spot on 🤷. It definitely had its moments, but I found this period a little tough because the vibe (for me as an exec on the team – hopefully not for most of the staff) changed. It kinda had to as we were now a PLC. At the end of a really exciting chapter, the start of the next one is always going to be a little underwhelming. Hard act to follow.
In early 2018, with the share price down but the NatWest arrangement working well, we received a very unexpected term sheet – the bank wanted to acquire the company. And after a lot of negotiations, they did! Funny how things turn out.
It seems pretty obvious in hindsight, but we genuinely had no idea that an acquisition would be 'a thing' at the time, but I'm glad it happened and not just for ££ reasons. It was, without question, the best outcome for the company since it brought investment, stability and a heap of opportunity. The last three years have validated this, especially during the pandemic. We’ve grown the business faster than ever, customers still love the product and there’s a rosy outlook.
It would have been tough to do that alone.
I have no plans for what's next, unless being focused on trying not to do anything in particular is considered a plan. I’m tired and I need a break – 15 years is a long time to be on call.
Starting another business, at least a high growth venture-backed startup, sounds a bit tiring right now but I wouldn't rule out an indie hack – I still love to create. I’ll see if there’s interest from other companies in advisory or non-exec positions and I have a list of "articles to write" which I've struggled to make a dent in, so maybe I'll write more. And take more photos. Or maybe I won’t!
Time will tell.
I’ll sign off with a few stats from my time at the company. I have no doubt these numbers will keep on rising, and I’ll be stoked to hear how things evolve in the years ahead.
E praeterito ad futurum! 💚💙
I was invited by Hao to do an interview about work/life balance on his popular Balance The Grind website recently. I received lots of nice feedback via my LinkedIn post so I thought I'd post the link up on this blog for any readers who don't inhabit social networks, 'professional' ones or otherwise.
You can read the interview here. I would love to hear your feedback on how you approach work/life balance.
Job ads which feature salary bands have been shown to be more inclusive and result in a larger number of applicants. Salary transparency is a staff motivator and increases engagement, so why are most companies still keeping rates secret?
I have no idea if this is a peculiarly British 1970s moment in time thing or whether it’s still a global phenomenon but I distinctly remember a birthday party some time around 1979 where I was blindfolded, spun around, handed a cardboard tail with a drawing pin stuck into it, and then asked to move towards a drawing of a tailless donkey and attempt to reattach the missing appendage to the hapless beast. I didn’t win (unless tails grow out of necks) but I’m pretty certain donkey champ Craig Hinchcliffe either had x-ray vision or possessed Houdini-like eyelids capable of pushing his blindfold aside.
This tricky stab-in-the-dark game came to mind when I was studying some job ads recently (for research purposes, I'm not sure I could cut it as a full-time programmer these days) and thinking about how companies determine what salary to pay people. The ads, like most you encounter, were well written if rather staid. They all had decent job descriptions, bullet points of requirements, but crucially there was no indication of actual compensation unless you consider terms like “market rate” or “competitive salary” useful. Why is this?
One reason might be because the company doesn’t actually have a clear definition of salary bands internally. This is pretty common and it's not necessarily a bad thing. The company need a programmer but they might not understand the market. You could apply, set out your demands and get the salary of your dreams because the employer hasn’t got the foggiest about market rates. Fine if you're an overconfident white male, perhaps less so otherwise.
It's more likely in 2021 that the company does have internal salary bands (or at least a budget the hiring manager has been told to stick to) but they think taking a more secretive approach is an advantage. If they let the candidates disclose what they want first then they can get away with offering less than they might have done. Clever, right?
Perhaps the employer thinks that putting bands on the job ad would prevent superstars from applying because the bands were not high enough? Keeping it vague might result in an inquisitive rock star dropping you a cheeky application on the off-chance, right? Maybe, but how many of these heroic applicants have you ever seen? Um, zero?
It might be considered risky to declare salary bands because the company could end up paying over the odds for someone and that would be wasteful. "Dammit Colin, if it wasn't for your pesky public bands we could have gotten away with hiring this person for £5k less!" It might actually be funny if this myopic attitude wasn't present in so many companies.
Finally, the absence of salaries might just be because the company is worried that their hard-working employees will figure out that they're not actually being paid particular well and all that talk of “competitive salary” is a ruse. Employees will always chat to each other about salaries. Don't say I didn't warn you.
I think you get my point. There is simply no advantage for a company to try and shroud salary bands in secrecy. If you are, you're doing it wrong and it’s no wonder you struggle to hire people or have team motivation issues.
Job ads with salary bands are more inclusive, will increase diversity, and result in more applicants!
Publishing a salary range is all well and good, but when you come to make an offer you have to nail down a specific salary. Some companies (especially those in the public sector) make this easier by having a single fixed salary for each grade. Most private companies don't appear to do this nor talk about what they actually do. It's something of a dark art (or a lottery) and definitely a topic for a future article.
When making an offer you shouldn’t necessarily pay people what they want as (a) it’s natural for an applicant to inflate their expectations during this negotiation period, and (b) it’s not unusual to ask people to reduce their current salary (e.g. for a change in sector or technology). Your interview process has to try and establish skill level relative to the band in question. It's super-hard and so it can be safer to err on the side of caution here (and perhaps this is controversial?) but it’s way easier on everyone to raise salaries post-probation than it is to red flag people and see them get stuck and demoralised.
To summarise, rather than blindly pinning the salary on the proverbial donkey my advice for leaders in charge of hiring (especially those in high-growth companies) would be:
Publish your bands on your job ads. If you’re hiring specifically for a senior person, put only the senior band on there. If you’d happily take someone at staff or principal level then put the whole range on there, but make it clear what levels this covers.
Publish your bands internally. I know this is difficult (“we don’t want marketing executives finding out how much engineers get paid”) and a bit of a minefield, but if you look at it objectively there really isn't any point in keeping it secret. Take control, talk about it and explain that you might make mistakes. People will value your openness.
Benchmark. Put in the effort and figure out where you want to sit against the competition. Forget FAANG and banking, they're outliers. Use Radford (if you can afford it) and gather your own internal and anecdotal external data. You'll quickly build up a picture and know what you need to do.
Review your bands annually. At least. The job market, especially in engineering, can move quickly and it's hard to keep up. This makes budgeting a complete nightmare of course, so become best friends with your CFO and CEO. The cost of dealing with leavers is huge, and it's far less expensive in the long run to pay the best salaries you can, as soon as you can.
I had a day "out of the office" yesterday (not to be confused with the previous 360 consecutive days out of the physical office since March 13, 2020). I just had a day off, which shouldn't be a particularly big deal. If anything urgent happened I would have received a phone call, otherwise I should easily be able to catch up with things on my return. I filter my email so it's a pleasant place these days, even after a few days without checking. Slack, on the other hand, is a complete disaster zone.
In my head I have long since departed all channels that I don't need to be in, and I only inhabit a few high-value, high signal-to-noise ratio ones. In reality, I have one day off and I'm snow-blinded by dozens of attention-seeking hashtags and red dots which results in a laborious routine of submissively channel-clicking and back-scrolling through history, desperately scanning for signs of value among a brain-frying array of links, mentions and updates. By the time I get to the end of it all I've forgotten most of it and bookmarked a few things which I will forget about and never return to until it's far too late. Even if I do remember, I will be unlikely to find those few nuggets of gold that I'm sure I came across because I can't quite make the search show me what I want. It's a context-switching nightmare. Is this progress? Is this effective collaboration and communication? Is this "work happening"? I recommend pressing Shift-Esc and moving on. If it's that important, someone will let you know.
The few channels I thought I was a member of turned out to be 157. At least I think so, because it's not something that Slack make particularly easy to find out. I guess highlighting this number to users might make them question the value Slack is adding to their day, and that question is probably not conducive to increasing weekly active users. I calculated it by browsing the channels then adding the Hide my channels filter if you wondered (972 channels – nearly 4 for every person!).
I've read a few books on the topic of Deep Work over the years which are interesting enough, but they can ultimately be summarised as something like: "turn off notifications and focus on one task for at least an hour or two". I even read recently about Deep Work as a Service. Concentration is now so hard to achieve it has been commoditised and outsourced to third parties to solve. This is dystopian stuff.
Unless we act this will only get worse. Relentless group chat updates, back-to-back meetings leaving no time to work on the actual meeting actions, 15 people gathering in a room without a solid purpose. We've all been there. Leaders and managers in business have a real responsibility to do their own 'deep work' and concentrate on understanding the long-term costs of working this way. And that means the cost to employees as well as to the bottom line.
Don't get me wrong, there is absolutely real value in these tools, it's just that it's suffocated by noise. To make progress, we all need to figure out how to suppress the noise in our workplaces and boost the signal.
We've been told that culture eats strategy for breakfast, and organisational health trumps everything else in business and I wouldn't disagree. Strong teamwork and effective communication are the best ways to build trust, and trust is at the heart of every successful team.
As a leader in a fast-growing company, one ceremony I've found crucial for encouraging effective communication is a weekly 'all-hands' meeting. This is an hour where everyone across the team congregates to share plans, ideas, stories. It's a place for sharing, to improve awareness, reinforce values and to help develop an inclusive culture which ultimately results in stronger trust. Every company should do this!
Originally, when our company was much smaller (say, fewer than 20 staff), we started a weekly all-hands as a 'sprint demos' meeting. We'd all gather at the end of the week and do a show and tell on what product improvements had been made. It was a bit awkward to begin with, but it was fun and we'd finish off by going to the pub.
As the company grew and the composition of the audience changed, the meeting structure evolved with talks becoming broader in scope, encompassing sales journeys, marketing initiatives and sometimes off-topic talks such as 'how to make delicious coffee' (I still follow this lesson) or in-depth explanations of how American Football works (I still genuinely don't understand). It was still fun! And when there were too many people to go down the pub, we bought a fridge and filled it with beer, wine and soft drinks.
The company all-hands was an end-of-week ritual that became established in the culture of the company. It was a safe, welcoming, inclusive place for everyone in the company to gather, be themselves and listen to colleagues from different areas of the business. The goal was for everyone to have fun and come away having learned something new, or gained a valuable new perspective. It worked, and it continues to this day, 4pm every Friday, in a rebranded 'Town Hall' form.
As the company grew, from my perspective the number of engineering-focused talks reduced and there became less of an opportunity for engineers to get into the weeds of the tech and maintain audience attention. Tech-focused talks are really important to a healthy engineering team culture, so we created a second weekly all-hands (4pm, Thursdays). This is held in the 'Town Hall' spirit, but the content is focused purely on engineering-related topics.
This engineering all-hands – or, as we call it, the Engineering Forum – has been happening every week since 2012, as I unearthed during some email archaeology:
Olly Headey Wed, 7 Nov 2012, 14:30 to Engineering
Don't forget we'll have our inaugral [sic] forum this afternoon at 4pm. There is no plan, and although I'll be present I will not be running it. All I would suggest is you bring your ideas, write them on the wall and we'll pick one topic (or more, if time) and go from there. The idea is it's run by you, for you!
Olly
The forum started small, had it's ups and downs as we tried to figure out what worked well and what didn't, but we persisted and it's still going strong today. We now have an engineering organisation consisting of over 115 staff, 50% of whom are fully distributed (of course, during this pandemic we're all fully distributed for the time being), so the engineering forum takes place over Google Meet.
There will be a range of talks such as presentations on a new product or feature, deep dives into the weeds of a refactoring, live coding demos (🙈) and sometimes lightning talks. It's really whatever people feel like talking about, frankly. They key point is the goal remains the same: to create a welcoming, inclusive environment for people to be themselves, and for everyone to come away having learned something new, or gained a valuable new perspective.
Things that I find work well in an all-hands:
Things that work less well:
Everything evolves over time and what works for a team of 5 probably won't work for a team of 50, and what works for 50 won't work for 500. You'll need to experiment and adapt to your audience, but get them involved in shaping it. Make it your own.
While the all-hands plays a vital role in communications, don't save everything for this meeting. An hour isn't long and it can (and should!) fly by quickly. You know you have to over-communicate everything, so make use of your announcements Slack channel and consider a long-form discussion forum as well (way better than email). Sometimes things are better written up, and often the real-time nature of Slack means that important things can get lost in the noise.
If you're not running an all-hands, give it a go. Maybe it won't work for you, but you'll never know unless you try.
Your first 90 days in a new leadership role (in particular, a VP Engineering or CTO role) will be largely spent in orientation. You'll be getting to know the ways and hows of the business in detail: its culture, its values, its structure, its current priorities, the things that work well and, of course, the things that don't. You need to see warts and all, leaving no stone unturned.
A big investment of time will be getting to know your peers on the exec team (your first team): what makes them tick, what are their strengths, what skills are they working on ("weaknesses"), what are their frustrations, what are their interests. Similarly, you'll be getting to know the people you're managing as direct reports. First impression count. On both sides.
Approaches to tackling the first 90 days in a leadership role have been well documented already, so in this article I want to focus on using a SWOT analysis-based framework for helping to identify the priorities of a department or organisation, in order to shape team strategy. This isn't a technique intended to replace the job of getting out there and meeting with as many people as you can – that's still crucial for building relationships and trust. It's a structure to use for an information gathering exercise that has proved really useful to me.
While it's especially useful for people coming into a new leadership role, I've found it really valuable as a recurring annual exercise to run in your engineering organisation. Change is the only constant in life and you need to keep up.
As defined by Wikipedia, a SWOT is:
a strategic planning technique used to help a person or organization identify strengths, weaknesses, opportunities, and threats related to business competition or project planning
Put simply, this means gathering views from across your organisation about what's good and what's not so good, both internally and externally. This diagram explains:
In order to gather the feedback, publish a Google Form (or similar) to allow participants to easily provide answers to the four basic SWOT questions, anonymously. The form goes to everyone, across the board – individual contributors (ICs), testers, engineering managers, IT and security staff as well as the leadership team. My form looks like this:
Allow people a couple of weeks to complete the form, you don’t want to rush it. Participation is optional but push for people to make every effort to complete it. You'll have to chase people (engineers typically have a lot on their plate), but aim for 70%+ engagement.
Once submissions are closed, you need go through the data and collate the responses into themes. There are probably some clever technical approaches you could apply here, but is it worth the time? For better I worse I always use a manual, brute force method which, on balance, is good enough despite being more art than science. It will take a good couple of hours to do this but that's fine because you probably want to read all the responses anyway.
During this data-wrangling phase, clusters of 'hot topics' will start to appear alongside a long tail of more fragmented ideas and feedback. The long tail ideas are interesting but it's the hot topics that will become your key areas for further discussion and prioritisation. You'll take these to relevant teams, start discussions, run workshops and eventually factor work into your roadmap.
The good thing about SWOT is that it focuses as much on the good stuff as the not-so-good. Don't just pay lip service to strengths and opportunities – these are the things that are working really well, and things to get excited about for the future. Analyse strengths and opportunities and see how you can capitalise on them elsewhere.
You don't want all the effort people have put into the survey to be left unrewarded, so it's important to communicate your results. Create a slide deck and present the results in your weekly engineering all-hands meeting (if you don't run one of these, this is your excuse to start!).
When taking the team through the results, I'll first present the previous year results (obviously only if we've run a SWOT before!) and reflect on whether we managed to take action successfully. It's important to look back and celebrate wins, however big or small – it's so easy to overlook this because it's natural to be looking forward to the next thing, and the next thing.
Finally, after presenting, I'll run a Q&A to allow everyone time to ask questions and give feedback.
The main point of running the survey is to identify actions to prioritise. I'll work with my leadership team on how we can work the most pressing actions into our strategy for the upcoming year and get them factored into team roadmaps. Some of the actions might be big-ticket projects which will require a lot of further analysis and discussion, but there will be plenty of low-hanging fruit as well.
Over the years I've been doing this we’ve had some really big wins. The first time we did it, the most problematic area by far was deployment pain. There were too many steps, not everyone had the ability to deploy, it was increasingly time consuming to get changes out of the door and we had no clear plan towards continuous delivery. As a result we prioritised the building of an entirely new CI/CD platform which had a dramatic effect on number of deploys per day and led to a happier and more productive team! It wasn't like we didn't know this was a problem before, but surveying the entire team and getting unambigious raw data from dozens of engineers gave us a much-needed reality check.
Of course the big wins are not a result of this particular framework. It's just one of many techniques you could use. The underlying message here is to give everyone on your team a voice and demonstrate that you are listening.
I was privileged to be able to speak at the Turing Fest conference in my home town of Edinburgh today. It's a "cross-functional tech conference" covering everything from marketing, sales, engineering, startups and business growth. I've been every year for the past three (or perhaps it's four) years and it's always been excellent. It's great to see such a high quality conference in Edinburgh, it's up there with the world's best.
The calibre of talks is generally really high, so I put in what felt like an inordinate amount of time preparing the talk. Partly this was because I really didn't want to cock it up, but largely because it turns out preparing a well-rehearsed talk - even a 30 minute one – is a mightily time-consuming thing to do! I really enjoyed the whole process – even delivering the talk was fun, if slightly surreal – but my respect for the speakers has gone through the roof now that I can properly appreciate the amount of time and sheer effort they devote to putting together their presentations.
Below are my slides. I'm not sure how much sense they'll make without the narrative so you should probably watch the video 😬
https://speakerdeck.com/player/21b81c1250d34e7385c5791a45b2fd07
Sometimes you come across a fantastic article that is totally relevant but seems positively jurassic in internet years. Maybe you actually read it at the time, years ago (especially if you're a quadragenarian like myself). If you did, maybe you even briefly experimented with the approach, but most likely you forgot all about it and moved on to reading the latest articles because surely they're more relevant and contain better advice?
This gem from Werner Vogels is twelve years old. It describes how Amazon approached software service development to ensure they remain "customer obsessed" (noting that the customer could be internal or external). It's as relevant now as it was in 2006 and it's a worthy reminder about why software development needs to focus on the customer, why it should always start with simplicity, and why software teams need to be brought together with a shared vision.
Suhail Doshi, founder of Mixpanel, posted a Twitter thread distilling a decade of experience into fifteen bite-sized ‘lessons learned’ since becoming a founder and CEO at age 20. It’s fantastic advice, not just for CEOs but for anyone in a leadership position having to deal with scaling a team or a company. If that describes you, at any level of experience frankly, you will be able to take something from it.
Certainly much of it compared with my own experience, especially these themes: delegate early, listen intently and learn voraciously.
Reading this letter from Bezos you can understand why Amazon are such an enormously successful company. He has built one of the most innovative companies in the work on clear, solid principles and he has obsessively upheld them by being consistent and by reinforcing clarity.
So much good advice in this letter to anyone involved in running a business. Essential reading.
