Killing The Sacred Cows
his place shall never be with those cold and timid souls who neither know victory nor defeat
Tags: business , delivery , development , governance
A lot of businesses say they want to be ‘digital.’ And I think when they say that they mean two things:
(A) they want to create an end-to-end suite of slick apps for their customers to enable them to self-serve, have a great experience, develop some love for the brand
(B) they want a delivery capability to make that happen, which must therefore include a good smattering of highly-motivated clever people who work together to build those apps according to a defined process so that anyone outside the build team knows what’s going on.
To get (A) you first have to create (B).
Last time I talked about culture and I’ve talked about process many times, so let’s take a different tack. Let’s look at 10 sacred cows that need to be killed to achieve (B). I am basing this list on 15 years of watching companies struggle to shed their non-digital cultures by ignoring simple but uncomfortable changes.
1. Location
I touched on this in Tech Culture but it’s worth being more specific.
Tech people hate commuting. It’s a waste of life. The most talented people used to congregate where they perceived the most interesting work to be. In the UK that was typically London or maybe the Thames Valley. If you tried to build a team outside of those areas you were fighting for the handful of people who’d decided not to live where the work was. Luckily that’s changed, but now employers need to wise up and catch up.
You have to offer remote-only roles these days. Not only that, you have to offer any damn arrangement that works for staff. That means remote, hybrid, office-based or quarterly meet-up based. It also covers abroad (within the constraints of tax laws) and on holiday if someone wants to work by the pool for a day or two.
That’s not to say face-to-face is dead. It isn’t. We love it. Provide generous funds for teams to rent shared spaces when it’s convenient for them to meet and collaborate too.
We know it really doesn’t matter where you are or even when you are (if you want to work asynchronously). Poor team players will be found out either way. You might as well be generous with your working location policy and use the money and time saved to improve workforce diversity.
2. Laptops
No member of a delivery team should have to work on corporate equipment unless they choose to. I don’t know why companies spend a fortune procuring laptops, crafting standardised operating platforms, and locking down the ability to use the device fully before handing them to the very people the company wants to be creative.
Clearly, there are lots of roles where this makes sense: finance, HR, and anyone with access to sensitive data. People will click on phishing emails, make copies of data onto USB drives and hand out their passwords to dodgy-looking websites. But for delivery teams, the speed of delivery outweighs the risk (which is reduced anyway in tech and product roles). Risks can be reduced further by adopting safe practices for account access, automated provisioning and de-provisioning and partitioning systems.
Developers especially should use whatever feels right. Which means desktop, laptop, tablet windows, Macs, Linux or whatever. There should be no rules about what the kit is and administration of it is the responsibility of the owner. I’ve seen so much time wasted by developers raising tickets for software upgrades, or the installation of new packages they merely want to try out. One organisation would make designers create a ticket and wait for fonts to be installed. And then we wonder why timescales slip.
Where laptops are provided they should be over-powered. The typical lifespan of a corporate laptop is 3-4 years. Software moves faster. Overspec today so it’s still useful in three years.
3. Tools
This is the laptop argument applied to software. Stop setting standards for personal tools. What matters is the output of those tools. This goes for IDEs, graphic editors, and word processors. Try lots of them. Fight and argue over which one is best. Then let everyone choose the one they like.
Set standards for the output if you need to. It’s wise to have a house style and be consistent about it. That’s what linters are for. Set your position on tabs vs spaces and let the war commence.
For collaboration use cloud-based tooling over locally installed software. This may seem somewhat against the principle just laid out, but it’s not. If it’s local, then don’t bother with standards, if it’s shared (like ticketing or workshopping) then pick a cloud service and force everyone to become proficient in it. Don’t download JIRA and run it on a work server, you just made a sys admin role you don’t need. Use the web version.
4. Don’t Buy Until You’ve Built
Never start a project with a third-party piece of software at its heart. ‘Implementing X’ is not a project, it’s the dependency for a higher-level outcome. The focus is the outcome. When you begin any piece of work assume there are no prior standards, no packages, no Oracle, no IBM, no Microsoft, no workflow systems, no e-commerce packages, no service buses, no document management tools, and no content management. As you define and understand the problem to solve you can make better choices about buy vs build.
That said, once you realise you are building something that you can get in product form, do not delay. Do not double down on your arguments for a bespoke framework because you are in some imagined way special.
5. Consultants
It can be extremely useful to bolster a team with external people. If you’re breaking ground with a new framework then having someone from the other side of the learning curve saves a lot of time. My approach to contractors is to treat them like permanent staff. Same care, same consideration, same time to talk.
Hire for missing technical skills and specific experience only. Do not hire outside the gaps. Do not hire trainers, coaches, scrum masters, evangelists or change consultants. I’m not saying there’s no value in the position, just that the market is awash with chancers these days. People who can tell good stories about projects they were on, or near, or heard about, but had no hands-on impact to. People who have mastered the process of interviewing but struggle to do actual useful things.
6. Expenses
Think allowances and stipends over purchasing. See point 2 above - don’t buy laptops, instead give a generous stipend to new staff to buy their own, then give them something every year to maintain or replace it. Allowances work for kit, office space, software, stationary, food, and socialising.
Financially the company will be better off for two reasons. Not everyone will utilise all their allowances. There’s no up-front sunk cost. If buy laptops you have depreciating assets sitting in cupboards when they are not used. Annual allowances can be earmarked and unspent amounts used for a better summer party. Also, buying things leads to governance: someone needs to enforce their use, police their application and ensure they are handed back when employees leave. That’s more HR staff. A notable aspect of digital business is low-profile HR. The CEO of the (very digital) Octopus Energy, Greg Jackson, caused a kerfuffle when he said they have no HR at all. He said that HR tends to infantilise employees and drown creative people in process and bureaucracy. Exactly the opposite of what a digital business needs.
7. Process
Yeah, I know I said I wasn’t going to talk about process, but it’s worth stating one thing simply: the vision for digital delivery is all about flow. Even if you don’t have it now, it’s important to have that as the destination.
Flow means something like Kanban. Flow means something like Kanban. Work comes in and priority work goes out continuously. If you don’t work in sprints, then start. If you work in long sprints then aim to shorten them. If you spend a lot of time fixing up releases then slow down, and get good at releasing before speeding up again. If work is manual then automate it. If you use scrum then lighten the processes over time. Look out for anti-patterns like scrums of scrums. Deliver vertical slices of value into production.
Look for less wasteful work over hiring more people. Hire new staff only when necessary. Question every function point, discard everything that can be left out. Work to the principle that the simplest software is no software at all.
8. Appraisals
Nearly every organisation I have worked in has had a dreadful annual appraisal process. They are time-consuming and pointless. I mean what’s the outcome anyway? Is it for career growth? Because that’s a weekly conversation, not an annual assessment. Is it for assigning the bonus? Well, we’ll come to that in a minute.
Either scrap it entirely (run for one year without one and see if anyone actually misses it) or replace it with something that’s quick, continuous, online, meeting-free and requires no cross-departmental levelling.
9. Teams
it’s talent and sweat
Teams should always be small and cross-functional. The only people on the team should be those with a vested interest in its outcome, not anyone with just an interest. And being in the team is two-way. You belong to the team and its results, good or bad, belong to you. You can’t dip in and out and you certainly cannot ever blame the team for something without blaming yourself.
A team is defined by its ability to create an isolated backlog of work. They need to talk to other teams but not to get their work done, or agreed, or scheduled, or approved. Anyone who provides those things is on the team and succeeds or fails with them.
10. Pay & Bonuses
When compared to normal jobs Tech and product people attract ridiculous salaries. We should admit that. We are very lucky to do what we do and be well paid for it. But salaries are high for a reason. It’s hard work that requires a degree of diligence and expertise and when it’s done well it’s worth millions to businesses. In fact, in extreme cases, it’s the difference between business success and failure.
Because salaries are high it’s tempting to treat product and tech staff like they owe the business something. They don’t. Or at least they don’t owe any more than what’s written on the contract. Salary is irrelevant. It’s set by market demand vs supply. If you want the best unfortunately you have to pay for it. So take the market median and pay 10-20% above that. Re-assess every year offer rises as necessary. Churn is a flow killer. It’s not worth going cheap.
And do NOT pay performance bonuses. There are few issues more divisive than asking managers (who rarely know what individuals have done or what they put up with) to assess people in order to pay them according to a scale. Everyone assesses themselves at the top. If you say the maximum bonus is 30% of salary then anything less than that will feel like an insult. Humans are strange like that. Talk of thousands for a while and hundreds is a slap in the face. It’s like Mo Gawdat says: happiness is minimising the gap between perception and expectation. I’ve pushed and prodded for individual bonuses to be improved many times. No one is ever happy, even if they win. If there’s spare cash at the end of the year, then give everyone an equal amount. It sends a better message - we all helped.
Notes
-
The image is a cartoonised photo from a set I took whilst visiting a Welsh dairy farm, looking into the application of blockchain technology in the food chain. The cow was not impressed by Merkle trees.
-
The subtitle is lifted from Theodore Roosevelt’s famous Citizenship in a Republic speech, sometimes referred to as “The Man in the Arena” speech. I like it because it reminds us that any experience beyond the boring watery anodyne middle-of-the-road type requires us to be out there, facing fears, making change, trying. I’m not especially keen on killing any cows, let alone sacred ones, but when it comes to accepted practices, we should be questioning them every day.