(upbeat electronic music) - Hello, everyone.
So I'm the Front-End Development Lead and I'm a director at Deloitte, Deloitte being a big audit and accounting company and Deloitte Digital being completely different and kind of a what looks like a really weird choice when I started there 11 years ago., that why would an audit and accounting company hire these dudes in t-shirts and jeans? But it seems to have paid off for us over the years which is pretty good.
So I started off my career doing Flash and HTML and CSS which probably gives you some idea about my age. Flash being the red there.
When I joined Deloitte, there were three front-end developers, nationally, and 30 people in the Melbourne office.
And I did a bit more Flash than HTML there because the other two guys didn't know Flash, so one of the first sites I was told to do was Here you are, Country Road, we don't know Flash, but they want it, so go nuts.
So that was pretty good, so I had to manage that. Over time it's kind of shifted a lot.
Steve Jobs announced in, I think it was 2010 or 2011, that we're not gonna support Flash, and so all of a sudden I was not doing Flash anymore. Probably a pretty fair point.
And then I started taking on more of a leadership role as the Tech Lead of the team, and then taking over the National Lead role and then becoming a director, not really doing any HTML and CSS anymore, but now I've got 40 people who do that for me, which is just quite fun.
And then I'll provide advisory to our clients and our team and then also the leadership of that team, and the structure of it and how we can manage the change and not go to far.
So that's what I'm gonna talk about today.
So change is inevitable.
Here's some of the different technology choices that I've had.
One of them was chosen for me, which was CoffeeScript. That was a nightmare.
Oh my god, I'm glad it's not around anymore. That was one project and it really hurt us for another two years after that, trying to support that thing.
But there's a lot of tech and changes over time. So a lot of these things are probably not really used any more and not used by us at least. So at a high level, what we needs is, we need to start with something.
So you kind of need a benevolent dictator.
The next step is to bring people in that you trust. And I'm going to call that a meritocracy.
And then after that you need to be open to change from all. And so we'll call that a democracy.
So we've got three different forms of government and three different forms of leadership that's gonna help us get to where we need to go. A lot of this is actually kind of linked to the size of your team as well.
So a benevolent dictatorship is going to go down a helluva lot easier when you've got three people in your team.
It might not work when you have a hundred.
So let's see what I mean.
So, benevolent dictatorship.
You need to know what good looks like for yourself. So I need to know what good looks like and what I want and then I need to make sure the team knows what my expectations are.
I need to have a set of fundamental rules and values that I use to base all of my decisions on.
Those values being the team values, or the rules being how do I choose my technology. Every choice you make as a dictator needs to be really clearly mapped back to one of those rules, because you need to have structure behind why you're making that decision.
If it becomes irrational, they're saying I want to use this tech just because, you don't get the buy-in from the team.
So what did I do? I created a front-end development style guide and a manifesto for the team.
And it really focused on just the principles behind it, not the specifics, but it was just there to say this is my belief in what front-end development is. This is what I believe.
You guys read it and understand where I'm coming from. The fundamental rules that we had for any tech choice that we made were it needs to look like native HTML and CSS and JavaScript.
Right, that was the big one.
CoffeeScript was one of the ones that didn't meet that rule and that hurt us, but native HTML, so using things like EJS over Jade.
CSS using SCSS over SASS syntax or LESS.
Because whY? Because we work with many, many clients and we need to take this tech with us and we need the path of least resistance for new developers to come in.
So the most baseline that we can get, that's what we're gonna use.
It needs to be well documented, supported and a clear upgrade path.
The clear upgrade path one was added after the whole Angular to AngularJS thing. It really needs to support customization, so that our creative designers don't need to care about the technology.
They can just go and design whatever they want and then we will come in and make sure that our sites don't look the same and the tech doesn't hamper our ability to be creative. Because we are working with many different brands, many different clients, we can't have sites that start looking the same.
There is also a clear way to move from whatever tech choice you had in the past to the new tech choice. There's got to be upgrade documentation there's got to be a new approach to how do I remove this from my project and how do I put this new one in.
So next up is meritocracy.
What you do is, this is the next stage right. Now you empower your senior team, a group of influences to help align to your original rules, right? Make sure that they're really aware of it, but then also help contribute to that as well. So you update your view of what good looks like based on what the rest of your team is kinda wanting to do. Like the rest of your senior team is trying to do. At that point, most of the time it's probably pretty aligned, but you do need to add or adjust the rules based on what that team view is, and sometimes that means that you as the previous dictator needs to make sure you're going to be open to change. And then what you do is create a process for managing change that is aligned back to those fundamental rules. I'll talk about the way we do that in a sec. So, with the help of my senior FED team, we updated our style guide and we added all the specifics in, so things like linters things like the good old tabs versus spaces debate. We sat down, we duked it out.
I lost a lot of them because there was more of them than me. But that was okay.
We now had a standard way of working.
I had to change my ways, so I used to do no space between the squiggly brackets.
I look back now, in CSS, I look back now and it was really stupid, but back then, it seemed a lot better for me at the time.
So, but I listened to my team, we changed it, muscle memory takes about four or five days to get right and then you're good to go.
What we then implemented was a change-one-thing policy per project.
And that was for, so the members of our meritocracy, the senior members, when they started a new project, they would look at one thing in that project from our base code library and they will say, I hate that the most I'm gonna change it.
And they come back to those values that we had before. They had to make the same decision, they had to think about the same ways that I was thinking about when I originally set the baseline and they needed to figure out how we're gonna change this one thing for this project and that's it. And then this will come into the next step as well, which is democracy.
So, anyone now on the team can suggest new changes. Right, but still it's that one thing per project. So each project is allowed to change that one thing. And that's okay.
So as a project team, the team will get together and they'll decide at the start of that project, which one thing do we want to change, which do we not like right now and they'll figure it out.
So, what they need to do after they've changed it and after they've run that project, they need to present back to the entire national front-end team, with the pros, the cons, what worked, what didn't work, and why is it better than the previous one that we had.
And they need to then prove to the entire team that it is a better choice.
The entire team will decide by general consensus if that change is better than the previous one and we might have a couple of projects use some new tech to try it out with another team, just in case, but in the vast majority of times, essentially it goes from that meeting, the team decides, maybe it has a chat about it on the team's channel afterwards, and then decides whether or not they want to proceed with it going forward.
And it's pretty quick turnaround.
Essentially, most of the time it's within less than two or three weeks after that presentation there's a pull request in the base repository. When it gets approved is another story.
So, any project can choose one thing.
We call it FEDeration, our monthly meeting, we lover our FED puns.
So we'll continue doing them.
We're showcasing that in that presentation, it's new tech, new ideas and suggestions for change.
And then also goes through an element of our framework as well, to help people who are new to the business understand it.
At one point we had five different icon approaches, from five different projects, because we use Grunticon, if anyone can remember it.
It was awesome, but a pain in the ass to implement. But it did everything.
And we couldn't find a solution that was easier to implement and did everything, because it had all too many drawbacks.
And so we had five different ones at the moment. Basically one of my team just decided to stuff it and he built his own.
And that solved all of our problems which was cool. This really helps new starters adopt our ways of working. The reason, how that works was that every new starter that we had come into our business they came in, and they said, oh, this is a shit framework, it's so old, and I hate it and it's antiquated and I don't want to use it.
And we had the whole team come behind them and say, hey, just give it a shot for the first one. And then come back to us after you've finished it. And more often than not, they'll finish and they'll go, hey actually that frameworks' pretty good. Can I just change one thing, and the answer is yes. Yes, you can.
But, you need the whole team to approve that. So, this approach helps us manage that change over time, because we're not doing it all really big bang, we're doing small incremental updates, but what it means is that every new project we do, we're not falling behind.
We're coming up with new things.
Now the biggest thing for us was, we went in on Angular 1, and then all of a sudden, with seemingly one blog post, we had three projects in Tech Dep before we even launched them.
And so then we had to go into React right, and so yeah, that was a big change and it was a lot of investment that had to be put into that next project, but it is just changing one thing, I guess. Angular or React, but it still gets you to that same approach.
You look at all of the tools and the packages that you use, a lot of them can be used interchangeably, so moving from say, Grunt to Webpack, changing linter configs, all things things can be modified quite easily, if you just take a small part of it to change, and get that incremental approach going across. So, Plato says "what is that disorder, "which is generated alike in oligarchy "and democracy and is the ruin of both?" Does anyone know what this is? And just by show of hands, actually, who hasn't seen the last season of Game of Thrones, and is worried about spoilers? Okay, cool, close your eyes for this next slide. I won't talk about it, but just the background might give it away, so you can guess who I'm talking about, I apologise, out of a 50 people survey, about 40 of them said I should keep it in, so I'm keeping it in. Tyranny.
Yeah, you can't really see the background, but you might be able to guess who I'm talking about. So, tyranny, this can absolutely happen at any of these stages, and you've gotta really be careful about it.
Factions can form in a democracy.
Absolutely, you might be seeing a certain country that that's happening in now.
Democracy can break down.
How do you resolve this without falling back to tyranny. When you're enforcing the decisions that people are making, so if a group of people are coming and saying I want to use CoffeeScript, I have to come back and say okay well here are the base values, here are the base fundamental rules that we've thought about this whole way through. You need to think about these.
Here are the facts, here are the pros and cons. You've gotta kind of destroy them with logic, right? Not, just 'cause I said so.
That's the difference between the benevolent dictator and tyranny.
So really be careful about how you enforce that change. You will see, and as having had worked at a large number of different companies as part of my time at Deloitte, yeah, you can see this a lot.
And a lot of it comes down to that fundamental reasoning behind why you're making a change or why a technology choice.
So many times I've heard, why did you choose LESS? Oh, because this guy just decided to do it. So, cool, but why? Oh, we don't agree with it, but we have to do it. It's like people aren't as bought-in to those technology choices until you've given them that ability to influence that change and understand the reasoning why behind the choices that you're making.
As leaders we sometimes need to accept a decision that we're not happy with.
If the logic is there, and they've baselined it back to all of the values and all of the reasoning and the pros and the cons are there, but it's something that you just don't agree with and you don't have the evidence to back it up, you need to be able to let go, and allow your team to have those decisions and make those decisions themself. And with these values and with these rules in place, they can make those decisions, and they can be empowered to do that, and it makes for a team that is a lot more bought-in to the way of working.
Now I have graduates who start, who have been at the company for six months, telling brand new senior hires, oh no, you definitely have to use this, because you have to look back at the rules, here's why we do it, here's how we do it.
Right, they've been six months out of uni and they're telling the 10 year veteran about the decisioning behind why we've chosen technology. Because they understand how I've decided, how my seniors have decided it, how our project teams have decided it, and they've bought in on it, and they're empowered to make that change themself. So, I'm going brazenly quickly here, but I tend to talk too fast, so I apologise. But let's just summarise on the takeaways, right. You want to start with a dictatorship, and this is actually really critical.
If you start with a democracy, you're probably gonna get nowhere, because then everyone has their own ideas, they're not clear on the way and the decisioning and the structure that you've got, they don't know what's right, what's not, they're not empowered to make that change themself, you've just got factions.
So start with a dictatorship, then get the people that make sense to you, that meritocracy, get the seniors and the influencers in your team, and in the meritocracy it might not actually be senior devs, it might be really influential devs.
It could be a junior developer, who's really influential with all the other junior developers.
Get them involved, get them on board.
You might have someone who's super, super opinionated, and we've all got those people 'cause we probably are them, but we've got those super opinionated people, get them involved.
Get them onside, because then they're gonna voice their opinion in favour of what the team is deciding to do.
And then get to that democracy point.
Establish those foundational rules and values. Do it early and derive every single technology decision that you make based off those rules.
This is gonna really help you make, when you have new rules come in, it's gonna help baseline the decision.
Allow anyone to nominate change, from the most junior developer to the most senior developer in the business, but it needs to be ratified by the rest of the team, so if you have a change that's controversial, get the team to decide.
Do they want to use it, do they not, do they want more information, do they want to see another project and how it works, do they have specific edge cases that they've seen in the past, this was the thing about the icon, the SVG Icons thing that we had, SVG fonts, icons the package SVGs that GitHub does, all the things have their pros, but then someone else is gonna say, yeah, but we use SVG icons like this.
Ah, shit, well we didn't think about it like that. These things, this is where your team and the breadth of the knowledge that you have on the team is going to come in to help you make those decisions. Try to avoid being a tyrant and accept that change is going to be made that might not be exactly what you're looking for. And ultimately, accept that change is going to happen. Right, we are in an industry where change happens every two seconds.
You've heard actually from a bunch of people already who are talking about change, who are talking about how you go out of the industry for two weeks and it seems like there's a new framework out there.
Because there probably is.
And so we need to keep up to date with that. And these rules, I feel help you make that change and help you stay ahead of the curve.
Cool.
Any questions? (audience applauds) (upbeat electronic music)
