Saturday, March 21, 2015

Get Curious

The best advice I’ve gotten in recent years is simple. Get Curious. For those of you who don’t know me personally, I can be rather aggressive, especially with things I don’t trust. Whether by virtue of personality or experience, my instincts always lead me to attack and take apart the unknown. This is in some ways a good trait in an engineer, after all, the unknown is what causes you to get paged at 2am. Unfortunately, when it comes to interpersonal interactions, aggressively looking for flaws in things you don’t understand looks less like smart defensive behavior and more like obnoxious trolling.


So how can one honor the need for clarity without attacking and picking apart things in a way that causes others to get defensive? The tactic I’m using is “Get curious.” Instead of assuming that the other party hasn’t thought of your objections, try to understand deeply the context in which they are making their statements. Why do they seem to want to do something that may sound illogical to me? What is their perspective on the circumstances? What have they tried to do already?


A few years ago I wrote about “Yes, and...” I won’t lie; I still struggle to this day with “yes, and”. For me, “get curious” is a bigger picture version of "yes, and," one that I find easier to keep in mind. If you’re always curious and looking for the context, you’re open to the possibilities that are out there. The possibility that you’re missing something important. And that openness makes people want to work with you.


“Get curious” could be the mantra for the learning organization. Curiosity in the face of failure, instead of blame, leads to a safe environment for people to fail, and lets us discuss our failures. Curiosity leaves us open to new ideas. Curiosity enables us to recognize our differences and embrace them to create a stronger whole.


So for those of you who are quick to blame and judge and want to get out of this habit, get curious. For those of you who feel like your team is afraid to take chances and fail, get curious. Even for those of you who are afraid that you’re being too nice and are not challenging your team or colleagues enough, instead of getting mean or aggressive, get more curious. You’ll be surprised at how much more effectively you can create change when you approach situations with open curiosity.

Sunday, February 8, 2015

On the role of CTO

I get asked frequently to define the role of CTO, and I thought I would share some of my thoughts.

First, let's start by talking about what a CTO is not.


1) CTO is not an engineering role. CTO is not the top of the technical ladder, it is not the natural progression for engineers over the course of their careers to strive to achieve. It's not a role most people who love coding, architecture, and deep technical design would enjoy doing.

2) From 1, it follows that the CTO is not necessarily the best engineer in the company.

Now, with that out of the way, what is a CTO, if not the best writer of code and natural conclusion of the engineering ladder?

The challenge with defining CTO is that if you look across the folks who hold that title you will see many different manifestations. Some are the technical cofounders. Others were the best of the early engineers. Some started at the company with the title, while others such as myself were promoted into it over time. Some became CTO after holding the title of VP of Engineering. Some focus on the people and processes of engineering, hiring/recruiting. Others focus on the technical architecture, or the product roadmap. Some are the face of the company to the outside technical world. Some CTOs have no direct reports, others manage the entire engineering organization.

In looking at these examples the best definition that we can make is that the CTO is the technical leader the company has in its current stage of evolution. To me, that is rather unsatisfying, and missing the hardest part of the job. I believe instead that the CTO should be the strategic technical executive the company needs in its current stage of evolution.

Strategic: Thinking about the longer-term, and helping to plan the future of the business and the elements that make that possible

Executive: Taking that strategic thinking and helping to make it real and operational by breaking down the problem and directing people to execute against it


So, what does a CTO actually DO?


First and foremost, a CTO must care about and understand the business, and have the ability to shape business strategy through the lens of technology. The CTO is an executive first, a technologist second. If the CTO does not have a seat at the executive table and does not understand the business challenges the company is facing, there is no way the CTO can guide the technology to solve those problems. The CTO may identify areas where technology can be used to create new or bigger lines of business for the company that align with the overall company strategies. Or the CTO may simply ensure that the technology is always evolving to anticipate and enable the potential futures of the business and product roadmap.

No matter what, the CTO must understand where the biggest technical opportunities and risks for the business are and focus on capitalizing on them. When you see a CTO focused on recruiting, retention, process and people management, that is because it is the most important thing for the technology team to focus on at the time.

Strong CTOs also have significant management responsibility and influence. This does not always mean that they are deeply involved in the day to day management, but part of maintaining your ability to shape the direction of the business and the business strategy is the ability to put people behind solving the problems you believe will impact the business. Other executives will have ideas and needs for technology. The CTO must protect the technology team from becoming a pure execution arm for ideas without tending to its own needs and its own ideas.

Things get tricky when the team grows to be very large, and the CTO starts to hire VPs to manage all the people. Many CTOs give up all of their management responsibilities to their VPs, sometimes going so far as to not even have the VPs reporting to them. It is incredibly difficult to maintain influence and effectiveness as an executive with no reporting power.

I saw this clearly at my previous employer, where the most senior members of the technical staff in large business areas would often hold the title of CTO for that area. These people were always highly respected and technically capable. They understood the business and the technical challenges for the business, and were often called upon to help inspire the engineering team and help with recruiting.

Their downfall was that they often lacked the direct management oversight of any teams, and because technology was frequently viewed as an execution arm, they did not have much strategic influence.

If you are a leader with no power over business strategy and no ability to allocate people to important tasks, you are at best at the mercy of your influence with other executives and managers, and at worst a figurehead. You cannot give up the responsibility of management without giving up the power that comes with it.

The CTO who does not also have the authority of management must be able to get things done purely by influencing the organization. If the managers won't actually give people and time to work on the areas that the CTO believes are important, the CTO is rendered effectively powerless.  If you give up management, you're giving up the most important power you ever had over the business strategy, and you effectively have nothing but your organizational goodwill and your own two hands. Hope you're really a 10X engineer!

My advice for aspiring CTOs is to remember that it's a business strategy job, first and foremost. It's also a management job. If you don't care about the business your company is running, if you're not willing to take ultimate responsibility for having a large team of people effectively attacking that business, then CTO is not the job for you.

Special thanks to my editors Amanda Peyton, Cate Huston and EIC ChrisK.

Tuesday, January 13, 2015

A Letter to My Team for Review Season

I wrote this email to my team and sent it yesterday. It covers some of my thinking about reviews, a perennially controversial topic everywhere. Even though I believe that it is not a perfect exercise, I think that the benefits can outweigh the downsides, and I cover some of my thinking here.

Team,

As you all know performance review season is beginning. I thought I would take this time to talk to you about the goals of the review process, why I personally believe in it despite its many downsides and inconveniences, and what I hope that you can all get out of it.

Why performance reviews?

The first purpose is to give everyone a time to reflect on the past year, the accomplishments and growth that we have each individually achieved, and to celebrate that. Yes, celebrate it. Take the time to think about not just what didn't go so well, but what went really well. Part of the training your managers receive is to dwell on the positive parts of the review. Many of us want to skip over that and get to the "areas for improvement", but there is as much value in knowing what you are good at and what others appreciate in you as there is in knowing what to change. We celebrate accomplishments throughout the year, but it's also important to take the time to sum them up. Learning happens when we study our successes as well as our failures.

Speaking of successes, spend time yourself accounting for them. Self-promotion feels bad to some people, but it is important to learn the skill enough to write about your accomplishments. Even if your current manager is excellent at tracking the things you have done and the skills you bring to the table, you will have many managers throughout your career and they will not always have this ability. We can work to change the world so that self-promotion isn't so important, but it is good for you to be armed with the basics for your future career. If you need help with this, talk to your manager, or feel free to stop by my office hours.

You will also get a chance to write and see a summation of areas for improvement. Hopefully you will take the act of writing this for your peers and manager seriously. This isn't the time to be petty but it is the time to be thoughtful and honest. Feedback for areas to improve is something that you hopefully hear as needed (and not just once a year), but we don't often have the time to take in the entirety of observed habits and behaviors throughout the year and comment on trends. I have gotten some of the most valuable feedback of my career throughout this process; if you're curious ask me about the time I got review feedback that told me I was creating a "culture of fear."

One of the most important goals of this exercise is for us to think about our company values and to reinforce those values throughout the team. You've all seen the list of company values over and over again. We celebrate them in team meetings and we talk about them in reviews because the values are what bind everyone in the company together. We can all exhibit them through the lens of our individual roles and skills. You were hired partially because we believe that you share many of these values and thinking about the great things you've done as expressions of these values helps us all remember what we stand for as a company.

Finally, there is the goal setting section. Goal setting is hard, and there's no reason it must be tied to the review, but this is a good opportunity to check in with your manager about what you like about your current job and where you want to change and grow. Do you want to speak at conferences? Become a tech lead? Move into mobile development? Start managing people? Maybe the answer is just "I want to keep getting better at what I'm doing now" which is totally fine. This is an opportunity to start making a plan with your manager about how you're going to achieve what you want.

I promise that your manager will put in effort to give you a thoughtful review and help you grow, and I hope that you will put in the effort to write thoughtful reviews for others. The prose is less important than the content, a bulleted list that says something meaningful is fine if that is your style.

When this is all done I welcome feedback from all of you as to how we can make the process better. I have gotten a lot of value out of my reviews over the years, above and beyond regular feedback, and I believe we can make this process worthwhile for all of us.

Happy writing!
Camille

Saturday, January 3, 2015

Meaningful 2014: Everybody Hurts (notes on SparkCamp)

It is valuable to get out of your own head, and see what others are thinking.

It is even more valuable to get out of your own industry and see what others are struggling with.

This summer, I had the privilege of attending Spark Camp: Visionaries, Leaders, and Managers. Spark Camp is a gathering focused on media and newsroom folks that also pulls from external areas including the arts and technology, and I was invited to attend as a representative outside of media.

To be honest, on the first day I was rather intimidated. I am not a creative. I am not a writer, a media luminary. Everyone there had done so much. Here was the choreographer of a famous musical! There was the editor in chief of a major magazine! The mayor of a city! The writer of a blog I love and admire! The head curator of my favorite art museum! (hello, impostor syndrome)

The sessions started, and we talked about problems we faced as managers. The challenges of performance reviews. Managing people from different generations. Some of the notes I took include:
"Performance reviews as a measure of culture"
"Vulnerability inspires investment. Management is not performance art."
"Designers and engineers both define themselves often by their process"
"Conversation's role in creativity"
"Victim vs Player: Teaching folks how to be players" (more on this some other time)

My biggest takeaway was that we in tech think we are dealing with a special situation, a special workforce. Knowledge workers who have options, who can strike out on their own, who are temperamental and amazing and can change the world or give us migraines. We are not alone. In fact, people in the media industry (and beyond) deal with the same thing. Writers and artists are not all starving, and the talented ones have as many options as talented engineers.

Similarly, I'm not alone in feeling creatively stifled by the challenges of management. People with backgrounds in the creative arts discover themselves with leadership positions that offer little time, space, or appropriate opportunity for creativity. Finding that creative outlet is a universal leadership struggle.

I'm grateful for the opportunity to get some perspective on my own battles, and share my experiences with a diverse group of leaders. We often see writing on "impostor syndrome" and tricks for combatting it. Here's my trick: say yes to situations, and try to handle them with grace even when you feel completely out of your depth. Because under the surface we all struggle, and we all doubt, and sharing those struggles and doubts with strangers is sometimes the best way to free yourself from them.

Saturday, December 6, 2014

The Best Decision I Made in 2014

Many people think that the role of leadership is decision-making. The desire to be the one who makes the calls drives some to climb the ladder so that they can become "The Decider."

I'm sorry to disappoint those who want this to be true, but in my experience the role of leadership is in fact to make as few decisions as possible, and to make the decisions that you are forced to make utterly mundane. Here are some of the mundane decisions I've made this year:
The first pass of a seating chart
Perfunctory approvals around uncontroversial hiring
Rubber stamping of well-thought-out architectural decisions
Signoff on budgets for vendor products we clearly need

I set up a lot of policies over the past few years. Some of them I've blogged about, for example, promotion committees. But I've also created policies around how new languages and frameworks are introduced, on-call rotations, even how we buy office equipment (oh the glamorous job of a CTO!). The goal of pretty much all of these policies is to make future decisions easier, and to empower various people on my team to make decisions without me.

So, I don't believe that good leadership is heavy on decision-making. That being said, you can't be a leader without occasionally setting a direction, which leads me to The Best Decision I Made in 2014. It started with a twitter conversation about continuous delivery, on January 3. I have been thinking about continuous delivery forever, and trying to move Rent the Runway in that direction for as long as I've been running engineering. At the end of 2013, we created a task force to make our deployments, then-weekly and taking up to 6 hours to do, faster and less painful. The team was well on their way to success by January 3. And so, inspired by my conversation, I sent this email:

Starting in Feb

Camille Fournier Sat, Jan 4, 2014 at 9:40 AM
To: tuskforce
I want the one ring to release every day. Even if there's no user visible changes. Even if there's traffic. Even if it means we break things
That's it. I held my breath to see the responses. And as they rolled in, one by one, all of the engineers agreed. They were excited, even! So I started to tell others. Our Head of Product. My CEO. I told them "this might cause some pain, the first couple of weeks, as we figure out how to do this safely, but it's important." 

And so, come February, we began releasing every work day. And it was glorious. 

What made this decision so successful? What did I learn from this?

A great decision is often not a revolutionary move. We were doing the technical work to enable this already. The team wanted to be deploying more frequently. All I did was provide the push, to raise the bar just a little bit higher and express my confidence that we would easily clear it. 

The thing I learned from making this call wasn't anything about the decision itself. It was about the process that got me there. You see, this came about right after new year's, when things were quiet at work and I had some time to sit alone and think (or, in this case, tweet). All the sudden, I had ideas again! And it hit me: I need regular time alone, away from meetings and people, in a quiet room with a whiteboard. 

So I started blocking my calendar every Wednesday afternoon, and things started to change for me. In those Wednesday afternoons, I thought through the next evolution of our architecture. I thought through our engineering ladder, and our promotions process. I thought about problems I was having with people and how I could make those relationships better. I did some of the foundational work to create the 7 completely new talks that I wrote and delivered in 2014. I made time for the important but not urgent. In short, I grew from a head of engineering focused on the day-to-day into a CTO who thought a lot about the future.

The best decision I made in 2014 wasn't, actually, to tell my team to release every day. That's just the story I've been telling myself all year. The best decision, really, was to make time to think.

Wednesday, October 22, 2014

"Meritocracy" and the Tyranny of Structurelessness

Engineers like to believe in the idea of meritocracy. We want to believe that the best idea wins, that the person who produces the most value is rewarded, that we judge only on what a person brings to the table and nothing more.

Nothing could be further from the truth, of course, because we are ultimately human, and humans are biased in many ways both subtle and not. This post is not going to attempt to educate you on human bias. If you're unfamiliar with this concept, I'd welcome you to watch this talk put together by Google on the realities of bias in the workplace and efforts you can take to combat this.

Now, all that being said, I love the idea of meritocracy. After all, I am a CTO, surely I am here mostly due to my merit! OK, even ignoring my own position, I would really like to create an organization that does behave in a meritocratic fashion. I don't want to say that someone has to have X years of experience to do something, or Y arbitrary title. I want to reward people who show up, take on big tasks, and produce great results.

The most common way that people at startups attempt to create meritocratic environments, to avoid this title-driven fake hierarchy, is to eschew titles entirely. Eschew titles, have "flat" organizations. Removing the trappings of hierarchy will mean that we are all equals, and will create a place where the best idea wins, right?


Removing titles and pretending that the hierarchy doesn't exist does exactly the opposite of creating a meritocracy. It most often creates a self-reinforcing system where shadow hierarchies rule the day and those outside the in-group have even less opportunity to see their ideas come to life. It frustrates newcomers, and alienates diverse opinions. It is, in short, the enemy of meritocracy.

What is a poor meritocratic-seeking engineering leader to do?

The only answer I have found is echoed in the video I linked above. Far from eschewing titles and pretending no hierarchy exist, you must acknowledge this reality. And, furthermore, you need to be really, really explicit about what it means to actually be working at the level indicated by these titles. You need to first, make it really clear to yourself what is required at every level, and then make it really clear to your team what it means to be at every level. 

This is not easy to do. My greatest fear in implementing this has been the fear that people will come to me and try to "lawyerball" me into promoting them to a level that I don't feel they are working at. Or that people will become obsessed with their title and constantly be trying to get promoted and treating each other differently due to titles.

To point 1, though, if a person truly is meeting everything I have laid out as being necessary for working at a level, why would I not want to promote them to that level? It either means that I haven't really articulated the level clearly enough to really encompass the responsibilities, or in fact, they really deserve to be promoted and I am letting my bias get in the way of evaluating merit.

To point 2, if I lay out levels that I believe are genuinely increasing in impact and responsibility and have high bars to clear, why would I be upset if people strive and work hard to grow into them? "Meritocracy" doesn't mean "Only reward people who are naturally gifted at what I value." That's the thing I'm trying to stop doing!

On treating each other differently due to titles, well, that's a two part problem. The first part is this: creating a culture where ideas are welcome from anywhere requires cultivation with or without titles. The second is that generally people get promoted because they have shown bigger impact and influence on the organization, and so it's not that surprising that they will have bigger voices. I'm not sure that is a terrible thing, if those people are living up to the high standards that come with that influence.

Finally, of course, to get a group to embrace this is tough. So why not take the decision-making power to promote people out of the hands of managers? That is what we have done in my team. We now use promotion committees, composed of engineers at a level or two above the person trying to get promoted. Now the whole team is bought into the idea that promoting someone is not a gift bestowed by management but an acknowledgement by a group of peers that one should join their ranks. 

This is not going to be perfect, and it is a lot of work for me to implement. But in my experience taking the time to establish clarity in anything is a worthwhile exercise, and creates a better and ultimately more efficient organization. 

Thursday, October 9, 2014

When Defining Reality, Don't Forget To Deliver Hope

I had a great 1-1 with one of my tech leads today, who came by my office hours and asked me for advice on becoming a better manager. I gave my usual rambling reply to broad inquiries; we talked about making personal connections, reading a lot of blogs and books, experimenting with different ways of asking questions to get people to reveal their true interests to you, so that you can better help to nurture and serve those interests.

But then, at the end, I had a thought. I asked him, how often do you talk to your team about what the future is about? How well do you know what the future of your team should be like? Not the product roadmap, which is in the capable hands of an amazing product lead, but the technical future. How to think about building systems that are future-thinking, becoming a better team, writing better code.

"Not that often" he admitted.

So, I persisted. How often do you spend some time away from your keyboard, away from the internet, away from meetings, and think about what you think the future of your team should be, the areas that you could focus on, the big opportunities for growth?

Again, the answer was "Not that often."

This is not at all surprising, of course. When you work in an industry where you focus on building out technical skills and getting more things done for the first many years of your career, making that shift into management (really a career change) can lead to the temptation to focus on solving today's problems now. Solving today's problems well is probably how you ended up rising into a tech lead role, and we all know that there is never a shortage of problems.

But when you focus on nothing but today's problems, even if you are a great manager who does everything right, you are unlikely to motivate your team to greatness, or inspire the level of loyalty and passion that makes a team gel and prosper. You are missing the one thing that you cannot overcome with great management skills. You're missing leadership.

You can be the greatest manager in the world, but without leadership and vision, your team will not be truly sticky to you.

Fortunately, leadership is not a skill you have to be born with. It just requires that you identify the future and articulate it. "Define reality, give hope." Too often first-time tech managers focus on reality. We're comfortable with reality, reality is our bread and butter. But the future? Painting a vision for the future, even the future 6 months out, is a risk. You may not be able to deliver on that future vision. It may not be the right thing to do when the time comes. Reacting to today is so easy, and trying to predict the future seems really hard

But there's a simple (note: not easy) secret to breaking that habit and creating a vision: practice. Get away from your keyboard. Force yourself to sit in an empty room with a whiteboard or a pen and paper and write some ideas down. Grab a colleague or two to brainstorm with if you need to, but do some of the work by yourself. Then start painting that future to your team. This is the most important thing you can do to become a truly well-rounded manager, and if you aren't doing it, block your calendar tomorrow and start.