My 3 leadership learnings from learning to code
[Or what I did learn from javascript 101, even though I am not a software engineer]
When I was young(er), I’ve started my career in multinational corporations. One of the key things which struck me at that time was that, even though each of this company was quite hierarchical, every manager must, to evolve in their career, have made a compulsory training on the field.
In other words, whether you are a finance or marketing director, you have to regularly play the role of a sales person in the shops, visit the factories or the place where the product come from to know where your product come from and really understand the value chain which at the end delivers value to your customer.
Then, nowadays, in such a global competitive environment and a world which change really quickly with the technological evolution, why wouldn’t any manager do a compulsory training “on the field” by putting themselves in the shoes of a software engineer?
According to the saying “eat your own dog food”, I’ve myself experienced the CodeSchool JavaScript classes, from scratch and here’s what I learn.
NB: I’m not sponsored at all, this is not a commercial post, just my feedbacks on my personal experience.
1. About focus
Photo by Dmitry Ratushny on Unsplash
What a software engineer can look like
From the outside, your software engineer looks like a teenager with the special combo jean/sneakers/headphones who doesn’t want to leave his·her eyes from the screen and sometimes, they don’t even take the time to leave their headset when you pass by to say hello to you… How irritating!
Myself in their shoes
*In the open space, besides my colleagues commercial executives and the partners.* I’m trying to solve my first JavaScript exercises. First thing first, I’m reading the wording of the exercise and I’m trying to understand what the aim of the exercise is. Since I’m doing a training for beginners, I can easily guess which function or which JavaScript notion I’m asked to use. Though, trying to understand to which functional needs the exercise apply is far more difficult.
In the meantime, 50 cm from me, my colleagues are having strategic discussions regarding to the next big commercial leads in the pipe and how the company will deal with this. There’s also another colleague just in front of me who’s asking me every 30 seconds the English version of technical words because he’s working on a commercial proposal...
Whereas I’m quite ok with multitasking when I have to shape up a Powerpoint presentation, here I’m really in difficulty. I lost a quite substantial amount of time looking for what I did wrong in my exercise: I forgot a semi-colon somewhere… Beginners’ classic fault, but a simple one mistake which could have been spotted if I were more focused.
So what ?
In my example, I just made a typo in my code… and that’s because I’m a beginner, please don’t take this the wrong way. Coding is about solving complex problems. Like writing, you have to think about the structure, maybe write some stuff, and then rewrite it. If someone is interrupting you every time before you finish a sentence, I guess you will lost motivation or even the track of what you were supposed to write.
As a C-Level, aren’t you going to solve complex problems too?
By having an executive assistant, aren’t you trying to cut yourself from constant interruption ?
At the end, that’s just about common sense, and as a C-Level-to-be:
- I guess I won’t need to spend my money on these kinds of offers to realize the impact of multitasking and focus.
- NB: As I said, I’m not sponsored at all, though, this place seems quite nice.
- I would endeavor to be exemplary on deep working session, especially because of the workforce of the future will be (and already is) feed with social medias, stories and so on...
2. About productivity
First impressions (or things I often hear in my working daily life)
People from your company has insisted on having a baby foot in the cafeteria, maybe a ping-pong table also. It’s quite trendy and it’s a nice stuff to show your interviewees. But WTF, to you, your software engineers are spending their time playing, taking huuuuuuge breaks and you really don’t understand how you can still get a ROI from them at the price you pay them.
Photo by Jordan Whitfield on Unsplash
Lessons learned from coding: hard work vs. deep work
Coding in javascript was totally new to me and at the beginning, even coding just few lines of codes to develop basics functions was really hard. I have sometimes spent a whole afternoon all by myself on an exercise without managing to solve it at the end.
At the end of the day, I was tired looking for answers on forums and not really motivated. Working harder (meaning here: doing extra hours) wouldn’t allow me to solve the issue. Best case who could happen: just copy/paste the answer of the exercise with no value-added for me in terms of improving my skills. Though, in real life, I would have written something quick & dirty which works but not good over the long term (if the code I had written was use in the real life).
How did I solve my issues (after turning the problem upside down all by myself): mainly by asking for the help of a more experienced person.
- Sometimes I answered myself the question just by asking it to someone else. Fun fact: I even learn this was called the rubber duck debugging and this name is so weird that I will remember it.
- The other time, the more experienced person explained to me how to solve it. Most of the time, it just took him·her a few minutes, and once I understand it I really got the notion which I was trying to learn.
My vows
As a C-Level to be, I will truly focus on the output of my teams and not their working hours.
I will keep in mind that to my teams, having breaks is part of their work days the same way they will have sharing times (meetings or whatever).
I would give them my trust and clear conditions to be autonomous rather than choosing a command and control leadership style.
Oh, and by the way, in my company we have a babyfoot and a flipper. At my client place, a PS4 and a pool table.
3. About the working tools
What you software engineer can look like
Same as point 1 above. You have actually no idea of what your employee is doing all day long (when he·she’s not playing ping pong or baby foot), except from the back, it looks like this.
Photo by Fabian Grohs on Unsplash
Plus, he·she dares asking you for extras such as giant screens or more powerful computers which costs a substantial part of their salary.
What I’ve understood by putting myself in their shoes
OMG coding could be soooooo tiring ! hehe
More seriously, my best epiphany on this topic concerns the crucial importance of the compulsory training on the field for the managers in my previous companies in order to understand where the products come from and understand the whole value chain which at the end delivers value to the customers.
Putting yourself in the other shoes tends to make you understand more the pain, the constraints and the needs of the people who are really producing on the field.
While it’s so obvious for anybody who hire a painter for a home renovation that he·she has to get quality brushes and painting in order to get the job well done, it is not for most of the C-level who “order” a brand new app to a software engineer. And why’s that ? Because he·she has no clue of what the job is.
So what ?
You probably think the painter example is a bad faith one. To give another one: have you already seen a trading room ? Do you know how much a Bloomberg terminal cost ? At this point, I guess 1 or 2 extra screens for 1 trader is not really an extra cost.
Let’s go back to our example. We talked of ROI previously. At the price your software engineers are paid, would you rather invest €1,000 more on each computers you give them or let them take a coffee every time they have to test something ?
While I have 100% the mindset of being rational, always seeking the ROI, calculating the costs and the gain in each steps of my decision. I also take into account the fact that there are hidden costs and gains that you can’t guess if you’re not on the field. For example, the cost of making your teams wait every time they have to test something. But also the hidden gain of having a great employee experience by provide them great working tools. As an illustration, my current employee asked me before my arrival which working tools I needed to among a small catalog (PC or Mac with 2 different configuration for each of them, mouse, bags…).
Modeling is great, but common sense would also add that: don’t forget you are managing people, not (yet ?) some machines which write code.
My invitation
Here, my invitation for you to try to learn how to code is not to masterize the skill, but to put yourself in other shoes and find what it can bring for you at your level, whether you’re a partner of a multinational companies or a program manager.
You can find herebelow more details on my JavaScript roadtrip but all I can say is that most of the insights I shared with you were obvious to me just after 5 to 6 hours of learnings.
For my part, I love working with the IT teams and Operations (marketing, finance, HR…).
This experience didn’t make me want to be a software engineer (like some HR colleagues who ended to be software developers). I would just go to play with some functions on Scratch with my nephew and niece.
Though, as an agile coach, it helps me on daily basis in my struggle to simplify the organization of my clients by scaling agile methodologies.
Extra advices
Photo by Fab Lentz on Unsplash
The Challenge in itself: don’t only choose what you want to learn but also the way you want to learn
Before starting the challenge, I’ve read the Beginner’s Guide to Web Development (approximately 40 pages) which explains technically how a website works.
Then, I’ve passed the following CodeSchool classes:
- HTML and CSS
- JavaScript roadtrip level 1, 2, 3
Why did I choose this one?
I had the choice between 3 technical certifications (decided by my company’s catalog): Java, Amazon Web Services, and JavaScript.
The Java and Amazon Web Services certification were the ones from the editors.
As I said previously, my goal was not to change my career path, but to enrich my technical general knowledge. Also, I was more attracted to learn about web front language in order to directly see the result of what I was coding.
Considering the fact I’m a consultant, the CodeSchool classes for the flexibility offer by e-learning methods were the best to fit my working lifestyle: you can do it whenever you want it, pause the video, accelerate it…
Keep in mind that coding is not something inaccessible
Anybody with regular brain capacities is able to learn how to code, there’s no need to sacralize it (even though it can really be a fascinating job) or to think it’s a trap.
It is not because you are traumatized by your mathematics lessons that you would not be able to learn algorithms or get the logic of any language. Actually, I often felt also I was learning a real foreign language with grammar rules and syntax. Just as much as learning anything new, you’ll learn coding making connections with was you already know, whatever this is.
Manage your time over the long run and be clear with your management
It takes a lot of time! and except if you can manage to do it in group for a whole day every week, you’ll have to make a trade-off between your current operations (i.e.: to contribute to make direct money for your company) and this challenge.
One of my colleague manage during his mission to do the “Google rule”: a whole day per week during 3 to 4 months.
As far as I’m concerned, I’ve picked another solution, more in line with my working constraints (actually the ones of my clients ;)): I did it by chapters, when the activities level was low (mainly school and bank holidays as I work in France).
Because most of us do not work at Google and get 20% of their working time allowed to personal projects, be careful and make sure with your managers and the HR you don’t put your evaluation and annual bonus in jeopardy.
To go further:
- https://www.codeschool.com/
- [In French] Décoder les développeurs, Enquête sur une profession à l’avant-garde, 2017, 180p. https://www.editions-eyrolles.com/Livre/9782212567397/decoder-les-developpeurs
- [In French] « Les leaders de demain doivent penser comme des codeurs ! », Interview d’Aurélie Jean sur le blog de la conférence USI, 31 mai 2017 https://blog.usievents.com/interview-aurelie-jean-les-leaders-de-demain-doivent-penser-comme-des-codeurs-pour-innover/