Part 2 in the Codemonkey to CEO series
Okay. You’ve said yes to the CEO position.
This is what you wanted; this is what you’ve dreamed about, what you worked so hard for … now what?
You look around the room at a group of vastly different individuals, from vastly different disciplines.
You know developers; you are a developer, you speak the language, you’ve learnt a bit about the landscape.
But what about designers? UX practitioners? Project managers? Testers? Sales people? What makes them tick? How do you make sure you’re empowering them for success?
Well, f&%$.
If you’re like me, you’ll think: “It’s okay, I’ve been leading a team for a few years now, I’ll draw on that experience … people are people. It doesn’t matter that they have different skills, right?”
Wrong.
How do you motivate people and empower them to soar if you can’t properly communicate with them? Hell, you aren’t even 100% sure what they do, or how their jobs work.
As my starting point, I wanted to understand as much as I could about these different disciplines.
What are their unique challenges? What does a “great day” look like for a designer? When does a UX practitioner feel they’ve not quite hit the mark?
The best way to answer these questions is from within. This can be a tricky situation. You need to remember that you’re the outsider, and it’s not your place to offer opinions. Don’t try and force them to work the way you do.
Show humility, be curious, listen and display a genuine interest and you’ll be exposed to a world you didn’t know existed.
For me the biggest challenge was to try not approach each discipline through the lens of a developer (what I “knew”), but rather to acquire entirely new lenses.
It helps that we’ve always had open people at Empire State who enjoy sharing. I believe that spending the time to try and get an understanding of people’s jobs and their contribution to the team fosters a relationship of trust which is also incredibly important for you as CEO now…
It’s up to you to define the vision and set the course, but you’ll never reach it without everyone pulling in the same direction.
A mistake I made early on was moving too quickly into the “where can we make improvements?” phase. While my intentions were good, this can come across as criticism, especially when you’re still viewed as an outsider. When you take the time to understand what it is someone does and to learn about their skills, you can work on and implement improvements together. Before that trust has been created, you can come across as someone who doesn’t fully understand and is just barking orders which will do no good for morale.
It may also be tempting to try and “bring everyone over” to your way of thinking. In my instance, that was trying to make everyone work and think more like developers. It’s a sure-fire way to alienate people, stifle creativity and kill productivity.
The reason you’re going to be able to produce great products is because of the cognitive diversity and varied skills of the team. So embrace and foster the differences; don’t try and homogenise everyone, no matter how much it might appeal to you to do so.
This process can take time, and it will. But don’t underestimate the effort or the importance of this phase. You’re putting together and solidifying the foundation of the company that you are now in charge of. However long you think this phase will take, double it – and enjoy getting to understand the variety of skills that go into doing what you do.
Photo by Ricardo Tamayo on Unsplash
