DEV Community: Ferno

(Book recommendation) Creativity inc. by Edwin Catmull & Amy Wallace

Ferno — Sat, 06 Feb 2021 14:13:29 +0000

I love Pixar since I was a kid. I grew up with their movies, being a 5 year old when Toy story was released. A Bug's life 🐞, Nemo 🐠, Up 🧓🏻 ... well, we could say that Pixar just nailed it, right?

I might be a little biased here, but I think we could all agree that Pixar became one of the most successful movie studio of the world. And they did that by being pioneers in their field: Computer graphics 🖥️. I have a huge respect for that. They delivered a lot of value.

Edwin Catmull, co-founder and President of Pixar and 2019 Turing Award winner, is one of the big minds behind the company, and together with Amy Wallace, they wrote the best-seller Creativity Inc.

This book 📖 is mainly about management and leadership. It gives you a pretty good idea of how a very successful company may grow, both with their virtues and their failures. I saw it as a way to avoid corporatization and how to keep a creativity environment 🤡. It's full of Pixar stories and also came with a nice description on how it was to work with Steve Jobs, which was very interesting.

Now, in spite of being a movie studio (quite ligated to software, of course, but a movie studio at last), I found several practices that could be very useful for any software organization. I think it has to do with creativity and how Pixar evolved around it, being creativity one of the top priorities, just as for any software company (being software development, as many claim, a craft).

So, the book is about growing, and growing in a good way 🌳. I'll list some of the topics/techniques that this book taught me.

WATCH OUT! SPOILERS AHEAD!

The Braintrust

Pixar relies heavily in this thing called 'The Braintrust' 🧠. They defined it as a periodic meeting where the directors/producers/writers discuss current under-development movies. The main point here is to give and get all the feedback possible, the good and the bad.

In short, the director/producer of the movie shows a draft 🎥, waiting for any little feedback that anyone could give. The meeting is not for anyone to come up with the way to make the movie better, but to help the director/producer to find that way and reach the goal. Just plain teamwork.

Candor

As stated in the book, the one thing that a company or team cannot lack is candor. If you are not able to give or receive feedback in an honest way, you are doomed, and you are not working properly with your teammates.

Indeed, this is vital for The Braintrust! Imagine a meeting created specifically to receive feedback and you get none or not an honest one! It could end in a disaster 👿.

There is a pretty known book called Radical Candor, which encourages a culture of feedback. I haven't read it (yet!) but it's highly recommended in the web and it might help anyone looking for ways to collect and give feedback in an organization 🙂.

Embracing failure

No leader should expect everything to work properly. It's virtually impossible to do everything right and execute every task with no errors. On the contrary, Ed and Amy tell us to promote a "research 🤓 ⇒ experiment 🧪⇒ fail ❌ ⇒ learn ✅" culture.

In a creative environment, experimentation is key to success. Instead of wasting a lot of time making a carefully designed plan and see how it fails during execution, we should be hands-on and fail quickly.

The thing is, there is no shame in failing or being wrong. We just need to learn from that event and make decisions based on that. And in this decision making is when a leader should be a real leader.

First of all, those decisions should be taken without much hesitation. A strong leader encourages a team to go through a certain path with conviction. If it's the wrong path, the leader should correct it and go on. With clear decisions, a leader could build trust from the team
Second, the leader is the one who encourages this experiment ⇒ success/fail culture. It's the person who needs to transmit trust to the team

The Hidden

Being a leader sometimes includes dealing with things that you are not completely sure of (well, that could be true for any job though). For example, being a technical leader, you may find untracked technical debt that you weren't aware of.

Now, what you need to be aware of, is that this unknown problems exists, and they may appear anytime.

What the authors tell us here is that a leader should be working in order to reveal this hidden problems. If a problem remains underground for a long time, it could be worse for the organization as anyone will be acting as it's not there, and it may explode anywhere anytime 💥.

Any teammate could help us here. I've known plenty of people that finds a problem (maybe, in a very bureaucratic process) and don't raise the hand and inform it. Maybe because that person thinks "this is the way it is done here". But that's a mistake! Everything could be improved! And the leader should be the person that discourages that behavior!

Final thought

There are plenty of other experiences explained in the book, mainly encouraging experimentation and discovery. An invention is not just a brilliant idea of some kind of genius implemented properly, but a mix of different experiences put together and figured out 💪.

Definitely a good read!

Happy reading! 🤗

5 points on a technical leadership role

Ferno — Tue, 22 Dec 2020 02:07:21 +0000

Photo by Rob Walsh on Unsplash

One day you are sitting in your chair, coding as usual, writing unit tests (right?), piece of paper at your side with a sketch of what will supposedly be the next rocking feature of your company's product. Everything is fine, life is going pretty well 💯.

The next minute you have a 1-on-1 with your manager, and she tells you that you were selected to be the team's Technical Leader! So exciting 😮! New role, new challenges .. and new responsibilities of course.

You may have some doubts about the position though, and it's completely understandable. After all, it won't be just coding, designing and bugfixing on a daily basis. From now on you will be accountable for the technical health of all your team's code and the technical skills of the people. This is something new for any developer.

But fear not! The road is full of enjoyment and learning. It will push you out of your comfort zone and improve your skills (yay! 💪). I faced this situation twice (maybe three times...):

The first time, in a small telecommunication start-up with roughly 50 people (7-8 developers). As usually happens in this type of companies, I was not only the tech lead, but also the functional analyst and the main developer. I was in charge of a whole solution and a team of 4. Surely was a roller coaster
Second time, in my current job. A much bigger company (~800 employees) with around 200 developers and more than 20 teams. I started as a developer and became a Tech Lead a year after, due to the growth of my team
We can say there was a third time, when my manager asked me to become the tech lead of a second team

Of course everything to be said about the role won't fit in a blog post. Nevertheless, I'll try to write down my two cents on some important topics, in no particular order.

Communication

Everyone says that soft skills are important in this role. And guess what? They are absolutely right 🙇.

As a software developer, you should communicate with your team, of course, mostly with other developers, your Tech Lead and your Manager. But as a Tech Lead, you will find yourself communicating with people in many other different roles and teams: Managers, QAs, Functional Analysts, other Tech Leads, Business stakeholders, upper Management, and so on.

Now, it's not enough to know how to write or speak properly. Take into account that you'll reach different roles and teams (in and out engineering), thus, you will need to prepare the information accordingly. For example, you will not be speaking of technical debt at the same level with other developers than with upper management or other business stakeholders. In one hand, you may talk about undesired dependencies between different modules and a lack of a proper interface for some of them. On the other hand, you may talk about how improving the code architecture could help adding features quicker in the future.

You will have different audiences and you will need to align your message based on that.

Become the technical face of the team

You will be accountable for every technical decision you and your team take. It might be not your entire responsibility (you may not be the one who decides to go this or that way in a specific feature design, because you might have autonomous developers in your team) but you'll need to be aware. You may find yourself talking about this decisions in a meeting.

There will be more meetings (as people will need a tech person from the team) and more questions to answer. Again this is not your entire responsibility ⇒ you may not be the one who answers every question, but you should take care of that and make sure the question gets answered. You may answer it yourself, or you may route it to another person. As a leader, you will have knowledge about the ownership of each developer in the team, so you may route the question accordingly.

Reliable source of information for your team

In this position, you will have more context. Either through meetings, or your manager, or random discussions, you will have more knowledge about the business and the roadmap of the company.

That gives you also the responsibility to transmit this information to the team. That way, your team would be aware of why we are doing certain things. What's this feature for? Why we put high priority on this refactor? Why...? will be pretty common questions, and you should have the information to answer them. Your team will trust you.

This information also gives you a way to prioritize certain technical debt. That is, if we are facing a specific feature next quarter, you may choose to pick a proper refactor from the tech debt backlog which will help to develop that feature quickly.

As I usually say to other tech leads, you don't have to know everything. Don't be afraid to say 'I don't know'. Be honest to the team and to yourself. In the meantime, you should be able to look for those answers.

Technical debt stakeholder

Now, you are the main stakeholder of the technical debt of your team. You need to create a plan to track it, control it and tackle it.

Check out some useful tools in your company. Make a list. Prioritize. Put some effort into making everyone understand the importance to reduce it.

Work with your team in a way to reduce it in a daily basis. It will be hard, but don't worry 🙂.

Also, be clear about it. Don't hide it. Try not having hidden debt. The most you know, the better you will prioritize, and you'll be able to come up with a better strategy.

Self-Awareness

One of the key tasks in this role is to build trust.

First, build trust from your teammates. A proper flow of communication and decision-making will be crucial.

Then, build trust from other Tech Leads and Managers of other teams. There will be times when they will reach out for help or the other way around. Trust will help things run smoothly.

But mainly, build trust on yourself. That's self-awareness. Be decisive. Be the best version of yourself. Be hard-working and smart-working (as much as you can at least). Demonstrate yourself that you can do this. You will find yourself actually growing, and, when you realize that, it's an amazing feeling.

One last thought...

Becoming a technical leader sure is a challenging task. You will soon realize the impact you may generate in the team and the company. It's gonna be hard, it's gonna be fun. Take the step!

At the end, you may end up figuring out how to put on a blog all the knowledge and experiences you faced in this role ... and finding that it's really, really difficult to cover everything. So you just make a list of only 5 points hoping it helps anyone (and hoping to write more about it in the future! 🙂).

Happy leadership! 🤗