A message to you, Rudy

Dear Managers,

Do you feel that your day is a conveyor belt of meetings, starting at 9AM and ending at 5PM?

Do you find that despite the existence of that space you left in your calendar, neatly hollowed out between stacks of meetings where you intended to eat your lunch, that yet again someone has booked in a meeting called “Quick chat” with no prior warning, without asking you for permission, without giving you any idea what it’s about?

Do you feel that your time outside of scheduled meetings is your own?

Do you find that on a rare day where you have three hours without meetings, you have absolutely no idea what to do with yourself, because you’ve been in reactive mode for weeks on end?

It’s time to take control of your calendar to create space for you. Yes, you.

Yours sincerely,

James

Management isn’t all about meetings

Having a chaotically rammed schedule isn’t a badge of honour. It’s the fast track to burnout, overwhelm, lack of future planning, and to being unable to pick up critical items immediately as they arise.

As you progress to managing more people, projects, areas of your application, or whatever you end up owning, you can easily slip into a continual reactive mode of operation. This is dangerous.

In this mode you are very rarely taking time to focus on the work you deem most important. Instead, you rely on others to tell you what you should be spending your time on.

I would argue that reactivity should only be part of your role rather than the whole. As well as being available by request for others, you should also be setting your own agenda for the improvement of the areas that you are accountable for. You should be blocking out time to do so, and defending that time rigorously.

But what should you be doing?

If you have become a purely reactive manager, then you may initially find it challenging to decide on what else you should be working on that isn’t just being reactive.

(I know. I struggled with the exact same thing.)

However, before we dive into exactly what you should be doing, we should look at the how.

Mindset

We begin with the adaption of a mindset that may feel peculiar to you if you have been existing reactively.

The mindset is that your time is important, and you are completely within your rights to control your time to increase the value of what you work on.

This can mean saying no to meetings, initiatives, chats, and anything else that isn’t helping you accomplish the goals that you, your staff, and your company has.

If you are being sucked into ephemera then turn it down. If some work could be delegated elsewhere, then do so.

Your time is precious. However, claiming it can be challenging. Coming from reactive mode into selective mode can make you feel as if you are being selfish, or self-important, or disappointing others.

Perhaps there are truthful elements to all of those self judgements, but regardless of whether you feel them keenly, you should be doing the correct thing for yourself, which should also be the correct thing for the business.

You should be spending your time on the most valuable things, and that should be applauded.

Practical implementation

So you’ve embraced the mindset. But what’s next? Claiming that space.

The way that I create space for myself in the week is by blocking out portions of my calendar. I used to leave parts of the day where I had no meetings as empty space, but invariably others feel that a gap in your calendar is an open invitation to claim it, so I began to take matters into my own hands.

By blocking out chunks of time with a calendar entry called “Deep work” or “No meetings please” or similar, others will think twice about booking over that slot when there is a legitimately free slot later in the day.

It’s easier for the booker to debate in their own minds about whether creating a calendar clash faux pas is acceptable, rather than you needing to have the conversation with them after they’ve claimed a free slot that wasn’t really free because you were actually using that time to work on something else.

Another possibility is setting the default visibility of your events in your calendar to private. Personally, I don’t do this, unless it’s for legitimately sensitive meetings, however having a blanket private policy means that people will be even less likely to book over one of your existing meetings because they will absolutely no idea what it is.

If you’re using Google Calendar, you can even set it to automatically reject meetings that are booked over ones that you already have in your calendar, but I’ve found that in practice this causes more pain that it’s worth, especially when your calendar automatically rejects that impromptu chat with your CEO because you’ve got “Lunch” there already.

Example activities

So now that you’ve nailed blocking out time in your calendar for yourself, what should you actually be doing? Well, that’s ultimately up to you, but here’s some ideas:

• Mentally “walking the floor”. In your head, iterate through all of the ongoing projects and areas of which you have ownership. What’s going well? What could do with more immediate support from you? Would any of your staff benefit from more time with you? Get it all out of your head into a list and contemplate it.
• Thinking and planning for the future. Reactive managers rarely get the time to get ahead on what’s next. What are the next projects going to be? Who is going to do them? Is there any work that we could be doing now that could ensure that future work is faster (e.g. building something as a reusable service versus just bashing out the code). What are other teams working on, and can any of it be of use to you? When was the last time you checked in with your peers? Are there any really annoying processes that need improving or killing?
• Putting time into initiatives that help more than just your immediate team(s). A while ago I wrote about Management Bugs, which is a project that started out of my own self-enforced deep work time. It was interesting to me, it helped out the wider department as well as just my staff, and it gave me wider input into teams that I didn’t normally work with.  What could you be doing to help out your department? Could you dedicate some time to code review of other areas of the application, or help set up a working group for a pressing issue that nobody has the time to move forward?
• Just thinking. A radical thing to do is nothing specific by default. See where your mind takes you. Walk round the block and it’ll find something important, I bet you.

One more thing…

There’s another benefit of blocking out time like this for yourself. It creates more space in your calendar that you can throw away if the proverbial poop hits the fan.

If the application sets on fire and needs all hands on deck, or if you have a difficult personal situation to handle with one of your staff, you can instantly cancel all of the commitments that you’ve set only for yourself, which makes you a more available manager them others.

That’s important.

People will wonder how you always manage to find the time to get critical things done so quickly. It’s easy when you can fight with your own time, rather than the time of others.

Facts!

If you’re a programmer, you’ve probably relished in some of the many Jeff Dean facts. Here’s a selection for you:

• Jeff Dean’s PIN is the last 4 digits of pi.
• Jeff Dean proved that P = NP when he solved all NP problems in polynomial time on a whiteboard.
• Jeff Dean once shifted a bit so hard it ended up on another computer.
• Jeff Dean can beat you at Connect 4 in three moves.
• There is no ‘Ctrl’ key on Jeff Dean’s keyboard. Jeff Dean is always in control.

Indeed, these “facts” aren’t facts at all, and there’s plenty more where they came from. If Chuck Norris is the embodiment of machismo then Jeff Dean has evolved into the industry’s manifestation of superhuman computer science wizardry.  

You may not know who Jeff Dean is, which, I must add, is entirely unreasonable. Let’s bring you up to speed. Aside from Jeff’s primary job, which is being the Internet, what else has he done in his career?

jeff.describe()

Before he joined Google in 1999, Jeff attained his Ph.D. from the University of Washington. His research focused on optimizing compilers. His research took him to Digital Equipment Corporation’s (DEC) Western Research Lab, before being convinced to come and join a young company with some interesting problems to solve. That company was Google. According to Slate, there were only around 20 other staff there at the time. It was very early doors at a pivotal company.

During the last 19 years, Jeff has co-designed and implemented a large proportion of the most impactful and world-renowned Google infrastructure, including numerous iterations of the crawling and search platform, the initial development of AdSense, Protocol Buffers, GFS, MapReduce, BigTable (which you may use as HBase), Google Translate, and more recently, TensorFlow. If you’re working in a software company solving problems with large amounts of data, you’re probably using a system or library that evolved from something that Jeff created.

Work

It’s no accident that Jeff has been involved in Google’s most innovative projects. In addition to being a programming sorcerer, he is equally good at helping others grow through his mentorship and technical talks, thus allowing others to multiply their careers by working with him. He also is highly respected and listened to by Google’s higher ups, making sure that he gets to place himself on the most impactful projects.

A candid Quora answer was written about what it’s like working with Jeff, which, surprisingly, isn’t all roses:

I worked with Jeff Dean for about a year when I was on the Google Plus team.

He’s mostly just a really friendly, smart, helpful coworker.  Like any other Google engineer, you could walk over to his desk, ask why a particular product worked the way it did and he’d give you a really good description of the decision factors and thought process that went into that particular architecture. He gave tech talks and demos to show his work and fielded questions just like any other senior engineering staff member.

But he was also a little intimidating. Jeff definitely has the ear of upper management and they give him free rein to pretty much work on whatever he wants to.  So if you’re working on a particular project that is at cross-purposes with something that he wants to do, then you kind of just get railroaded because his code is getting *launched* no matter what…  So you may have to just adjust your plans to accommodate!

So there’s a bit of “jujitsu” to working with high-powered folks like him — you find ways to align your projects so that their weight is being thrown in behind you, not against you.

Partnership

A recent New Yorker article gave a candid insight into Jeff’s life and also his partnership with Sanjay Ghemawat. The pair work inseparably, often choosing to pair program together, bouncing ideas off each other whilst one forges ahead on the keyboard. They worked together in a similar fashion at DEC. They even live inseparably: “Uncle Sanjay” often comes to dinner at the Dean’s household on Fridays.

To the purist programmer, and aspiring technical wizard, their situation seems perfect: two best friends working on the most interesting problems, together, in a trusted self-directed manner, free from the pressure of typical feature delivery and sprints. They’re some of the world’s best engineers, so they just get on with what naturally comes next, since they are implicitly drawn to the problems that are on the cusp of innovation that will be impactful for Google.

The reality for the 99%

But, as you’re reading this, you’re probably thinking that’s all well and good for Jeff and Sanjay, superstar engineers who have actually changed the world: they can have their freedom, but we can’t. They were in the right place with the right intellects at the right time.

Instead, us less-than-geniuses get our silly deadlines set by people who don’t know anything about engineering, we get processes and ceremonies that detract from actually getting good work done, and we sit in crowded open plan offices where we constantly hear noisy sales calls on the phone all day. Good for them, we say. Good for them.

Here’s the question: are Jeff and Sanjay a direct consequence of right brain, right place, right time, or is any of their situation replicable within our own working lives? After all, their situation seems unreachable. The New Yorker describes the leveling system within Google’s engineering department as follows:

Today, Google’s engineers exist in a Great Chain of Being that begins at Level 1. At the bottom are the I.T. support staff. Level 2s are fresh out of college; Level 3s often have master’s degrees. Getting to Level 4 takes several years, or a Ph.D. Most progression stops at Level 5. Level 6 engineers—the top ten per cent—are so capable that they could be said to be the reason a project succeeds; Level 7s are Level 6s with a long track record. Principal Engineers, the Level 8s, are associated with a major product or piece of infrastructure. Distinguished Engineers, the Level 9s, are spoken of with reverence. To become a Google Fellow, a Level 10, is to win an honor that will follow you for life. Google Fellows are usually the world’s leading experts in their fields. Jeff and Sanjay are Google Senior Fellows—the company’s first and only Level 11s.

Here’s another thought: if 31 year old Jeff and 33 year old Sanjay turned up at Google today, would they be given the same freedom and autonomy that they currently have at 51 and 53? Or would they end up in a regular development team for countless years, working on a tiny, tiny cog in a gigantic machine?

A formula for success

We could make some hypotheses about why Jeff and Sanjay have been so successful.

• Preparation. They are both extremely smart individuals.
• Luck. They joined a world-class company at a critical time in its growth, allowing them to work on the most important problems.
• Riding the company growth curve. Their success in said problems allowed them more and more access to two critical things: the ear of the upper management and the visibility of the cutting edge of their domain.
• Earned autonomy. Trust from management allowed them their own choice of work and protection from less innovative projects taking their time.
• Multiplied output: Access to innovative work allowed them to apply themselves to the problems that made themselves and the company grow.

Not all of us have the fortune or geographical placement to get a foot in the door at the very beginning of the next Google or Facebook. However, there are ways that we can create opportunities for our staff to emulate how Jeff and Sanjay work once we get our departments to a reasonable size: say to the point that there are a small handful of engineering teams.

What we can do is to add roles to the top of the individual contributor (IC) track that allow staff to become more self-directed, to propose their own projects, and to live outside of traditional teams.

The top of the IC track

A year ago at Brandwatch we promoted a small number of senior and long tenured staff to the position of Principal Engineer. This isn’t a role that we have invented; a quick search on Google will show you that it’s pretty well known and has been around for a fairly long time. For example, Jay Kreps was a Principal Engineer at LinkedIn when they were working internally on Kafka. There are similar role names at similarly large companies, such as Distinguished Engineer.

Engineers in these roles aren’t just hitting deadlines by clearing out tickets. Instead, as described by Drew Eckhardt, they’re doing work that materially improves whole company gross profit. This can be innovative architecture that leads to new products, scaling and optimization that saves significant percentages of company budget, and acting as a role model and coach to other engineers who become dramatically better at their job for spending time with them.

From my research, the role at companies of that size can often include management. An answer on Quora suggests that people at this level at Google (Level 8+) have more than 50 people in their division. However, we are not at Google size, nor did we want to blur our individual contributor and management tracks together.

We kept our Principal Engineer role solely about the engineering, because that’s probably what Jeff would have wanted if I could hire him.

How I implemented a Principal Engineer role

We have an Engineering department of around 160 people. We wanted to allow the chance for our best performing senior engineers to break away from the traditional scrum team format and to become more self-directed in their work. The exact reporting line differs in our numerous divisions, but I wanted to share with you how it works in my division.

I run the Applications division, which is mostly focussed around a suite of our core SaaS products. This does involve a number of interesting infrastructure and architecture challenges, but the bulk of the development effort is closer to the user: much more so than the division working on our web crawling, data infrastructure and primary storage.

Due to this, the roadmap of my division is primarily led by Product rather than Engineering. Carving out the space in order to do Engineering-led innovative projects – notably those that may not have a immediate pay off, such as infrastructure that can invent new product possibilities – can be hard to prioritize against Product’s feature roadmap.

To reuse a compiler optimization term, I hoisted the promoted Principal Engineer out of a team and had them report to me instead.

The Principal Engineer’s own work stream is set mutually between myself and them. This sometimes means that they are working alone, and sometimes they may be doing some work for one or more teams. This allows them to be a welcome addition to any given project, rather than a spoken-for resource that could do any old piece of work dished out to them. It protects their time and their interests.

A recent article from Silvia Botros, a Principal Engineer at SendGrid, and the accompanying comments on Hacker News highlight how the Principal role requires cross-organizational collaboration, whole department and company understanding, and strategic thinking about where technology is going, both inside and outside of the company. This aspect is the key that sets Principal Engineers apart from their Senior Engineer counterparts.

Some of the traits that we outlined for Principal Engineer are below. These traits form part of our internal career tracks document.

• Experience: Typically has 10+ years of experience. May have previously been a Senior Engineer, Principal Engineer, or CTO at a start-up. Is a deep technical expert in their area and has a drive and vision for where we should be going in the future.
• Technical knowledge: An expert, potentially at a global level, in their area. Designs, builds and suggests architecture that will grow the company in the future. Has a track record of leading the design and implementation of high risk or mission critical projects, particularly those that require the application or invention of new technology or techniques.
• Mentorship: The go-to mentor and confidante for our engineers. Is an expert and patient teacher.
• Consensus building: Champions new technologies and the modernization of legacy systems. Is able to win the hearts and minds of senior leadership in the company and also motivate and drive their colleagues in Engineering.
• Conflict resolution: Can contribute to discussions and even resolve conflict at a senior leadership level. Rides the balance of business needs and engineering needs expertly.
• Time spent reading or writing code: 75%+

Currently, our three core products have one Principal Engineer mapped to each of them. As far as I can tell they are happy in their roles, but I’m sure they can correct me in the comments if they’re not.

It’s working out pretty well so far. The Principal Engineer in my division has delivered a new distributed bitmap index system to speed up our products. In another other division, we led a major project to rearchitect our storage to deliver 50x speed ups for our customers with the largest data sets.

In summary

You and I will probably never be as successful as Jeff Dean or Sanjay Ghemawat, however, we can create the space within our organizations to allow others to form similar skills and work on highly interesting and challenging problems.

Implementing Principal Engineer roles, even at smaller companies, can have an extremely positive effect: it can champion engineering-led projects, give individuals great career growth, inspire others to stay on the IC track rather than jumping into management for progression, and, most importantly, can result in the invention of some excellent technology.

Who could be your Jeff Dean? Think about it.