5 Time Management Tips That Will Boost Your Career

Last week I discussed my one tip that will help your career more than anything else. Along with continuing to learn one new skill every year, there’s something else that will help you to be successful: Being in control of how you spend your time.

I’m often asked, “How do you get so much done in one day?” and my response is always this: “Simple. I schedule my workload every day.”

When a friend of mine asked that question and heard my response she was horrified. “Oh, I could never do that. I’m just not a structured kind of person. I’d rather see how my day is going and how I feel, and then decide what I work on throughout the day.”

Everyone has differences when it comes to the way they approach their work. My friend happened to be the type of person who liked living from one moment to the next, handling things as they arose. But the issue was that she wasn’t receiving the pay raises or promotions she had been hoping for.

So I gave her a fun little exercise to do: Document what she did every hour of each day at work for one week. When we sat down to chat afterwards, she was almost bursting to talk. “I can’t believe how much time I’ve been spending on emails! And I also realized how much I get distracted from what I planned to do and end up doing something else.”

Sound familiar? It can be easy to get sidetracked at work when you don’t have clearly defined goals for what you’re trying to accomplish each day. If you want to achieve your career goals, one of the first skills to master is time management. Here’s how:

Find out where your time goes. Track your time for one week and then analyze the results.

Plan ahead. Sit down in a quiet location for 15-20 minutes and plan your week ahead. Write down the key projects and tasks you need/want to accomplish.

Prioritize. Rank your list so you can see the most important activities all the way down to the least important.

Block time on your calendar. Schedule the time you will need to complete your high-priority tasks and projects that week. Then, block out time for your medium-priority activities. If you’re out of time for the lesser priority items, you may need to push back on certain requests, ask for more time or work longer hours.

Carve out email time. Set aside specific times for checking your email, such as at the beginning of the day, right before and after lunch, and at the end of the day. Avoid checking email except during these times, as it can become a huge time sinkhole and distract you from your high-priority work!

The more disciplined my friend became managing her time, the more of her professional goals that she was able to accomplish. All it required her to do was to reframe her thoughts from “I wonder how my week will be?” to “Here’s what I’m going to accomplish this week.”

Lisa Quast – Forbes

An Influential Thought Leader Live By These 3 Principles

I live my life by a few very basic principles:

  1. If you only focus on how much you can give, you never have to worry about who takes and doesn’t give back.
  2. There is no sense in debating the strategy of something unless the ship is already moving (“You can’t steer a stationary ship”).
  3. You are both what you say you are—and what you do on a daily basis.

In short: I care far more about the process than I do the destination. Because I’ve learned there is no destination to begin with unless a process is in motion.

When it comes to marketing and “messaging,” these basic principles don’t adjust much:

  1. If you only focus on how much you can give, the less you’ll have to sell.
  2. There is no sense in debating the strategy of something unless the ship is already moving (“You can’t steer a stationary ship”).
  3. You are both what you say you are — and what you do on a daily basis.

I’ve built a career for myself explaining these principles to other people.

When I first started writing on Quora when I was 22 years old, fresh out of college, my only intention was to write things people wanted to read.

My dream was to become a successful author.

In the process, I learned the art of “writing things people want to read” is actually an extremely valuable and versatile skill set. It’s the reason why, at 27 years old, I’ve found myself with “a seat at the table.” I am constantly the youngest person in the room. I am never (not by a large margin) the wealthiest person at the dinner. I spend more time talking to people whose net worths are north of $50 million than I do my own 20-something peers—that’s just the nature of working exclusively with C-suite executives and successful serial entrepreneurs.

Principle #1 for me is to give 100x more than I ask in return.

This has stabbed me in the back a number of times.

I’ve had people steal my work word-for-word and put their name on it. I’ve had people offer “mutually-beneficial partnerships” where they extracted as much value as possible without giving anything in return. I’ve had people ask for my help with a handshake and a promise that they’d return the favor—and then went MIA. I’ve had people sign contracts with me, only to pretend like they never existed.

But those wounds pale in comparison to the opportunities I’ve gained as a result. By giving, and giving, and giving, for every two of those unfortunate circumstances there are two hundred other positive results.

Someone stole my work. Sucks.

Lots and lots and lots of other people saw my work, loved it, and paid me handsomely to do the same for them.

Someone didn’t return the favor. Sucks.

This morning I woke up to 5 inbound consulting emails, 2 referral emails, and a new client.

If you want to become a thought leader in your industry, this is just part of the game. It’s the people who spend (waste) more time counting their losses and chasing down old promises that lose sight of the next they need to take. And it’s the people who are so afraid to give, that probably don’t have much worthwhile to give in the first place.

Principle #2, “You can’t steer a stationary ship.”

The worst mistake a writer can make is to sit there brainstorming, tapping his or her pen on the desk, refusing to put down the first word.

Because any good writer knows the moment that first word comes out, oh well then the second one goes there, and the third one comes next, and well what if we changed the second word so then we could use this forth word—and so on, and so forth.

That’s because nobody “brainstorms” a novel. Just like nobody “brainstorms” a great product or service or company. Building anything requires doing, and then reflecting. Doing, then reflecting.

As a mentor of mine used to say, “Brainstorming is like mental masturbation. It feels good, but does it really get you anywhere?”

The vast majority of advertising and public relations firms like to position themselves as “strategy experts.” Everybody loves being the strategist. It’s way more fun to sit at a table and “brainstorm” really great ideas, show up, wave your hands around and paint verbal pictures of a better future, and then close out the presentation with, “Now you just have to find someone to execute it.”

I find that entire charade to be an incredible waste of time.

You know at the end of The Big Short when Mark Baum asks, “How much bigger is the market for insuring mortgage bonds than actual mortgages?” That’s pretty much advertising in a nutshell. People would much rather direct traffic than drive themselves (lots of wordplay in that sentence).

Whenever a client asks me, “What’s our strategy?” my response is, “Start with a few broad topics, and go from there.”

Some people don’t trust this process. I honestly don’t know any other way.

Going back to 22-year-old Cole writing on Quora, I didn’t sit down that first day and said, “Here’s how this is all going to play out.”

Not even close.

I sat down. Wrote my first Answer. Scrunched my face because it wasn’t my favorite. Forced myself to hit Publish anyway. Went to sleep unsure of what I had written. And then woke up the next day and did it all over again.

900+ Quora Answers400+ Inc Magazine columnsa book, and hundreds of guest blogs later, and I’m the 27 year old they bring in when they want their company’s message not to get lost in the noise. And the reason people trust me when I say, “The strategy is to start and adjust from there,” is because I write every single day. My body of work online is a testament to my unique approach.

Which is why I tell people all the time, if they want to become an influential voice in their industry, you can’t just sit there and think you’re going to have it all figured out before you start. At best, pinpoint a 30,000 foot goal, work backwards to come up with some general concepts, and then begin.

Principle #3: You are both what you say you are — and what you do on a daily basis.

Over the past 5 years, I have turned well over 100 people into industry thought leaders.

These are people who came to me—everyone from peers and friends, up to C-level executives—and wanted to know, “How do I build a personal brand, similar to what you’ve built for yourself?”

Going back to Principle #1 here, I’m going to give you the same Answer I tell anyone and everyone.

It’s a pretty simple process:

  1. What do you know? What are you an expert in?
  2. How do you know what you know? What taught you? Who taught you? What was a moment in time where you learned that lesson?
  3. Say those two things, over and over again.

The people who really listen when I share this advice with them have gone on to see the exact same results.

  • They started writing regularly on Quora and/or Medium.
  • They changed their bio to say, This is who I am and this is exactly what I do.
  • They started writing from a place of experience, sharing both what they know and how they learned it.

I’ve watched and helped people take this advice, put it into practice, and rack up millions of views on their content. I’ve watched them get republished by major publications. I’ve watched them become advisors on massively successful projects. I’ve watched them make huge leaps in their careers, all because they claimed their land and trusted the process.

I have more emails than I can count from people who have read something I’ve written, applied it to their own messaging, and seen its impact.

Now, here’s what happened to the people who failed to listen:

For every one of these success stories is a whole handful of people that want the “shortcut.”

  • They want their first article to go viral (it won’t).
  • They want every article to include the phrase, “…and that’s why we created our amazing patent-pending product that is revolutionizing this billion dollar industry.” (nobody cares—that statement doesn’t add value to the reader)
  • They want to know how they can get more press (if you trust the process this happens on its own).
  • They don’t want to share anything personal but they want to stand out (that’s like saying you want people to see your light but don’t want it to be dark outside).
  • They want all the big, shiny results, but only want to put out a few pieces of content (even Richard Branson and Elon Musk have to stay active on social media to stay relevant).

This is precisely why I say: You are both what you say you are — and what you do on a daily basis.

Imitation thought leaders are really great at the first part of that sentence.

They pay a PR firm to make sure columnists are saying incredible things about them: (“Enter: CEO Name, who has been amazing for over 20 years.”)

Their website is covered in self-promotional copy devoid of any substance as to how they actually do what they do: “We build meaningful partnerships between likeminded consumers and synergistic partners.” (Whatever that means)

They pump out content rigorously sculpted by an internal communications team that does absolutely nothing for a reader except push the company’s agenda.

But real thought leaders know their priority should always be on the second part of Principle #3.

and what you do on a daily basis.

You can’t expect a press piece to move the needle very much if the columnist is talking about what a powerful voice you are in your industry, only for a reader to Google your name and find a bunch of empty social profiles—or worse, nothing at all.

You can’t expect people to be loyal to you and your words if you aren’t loyal to them and their desire to learn something from you on a regular basis.

You can’t expect an ad to make someone sit back in their chair and say to themselves, “Wow, I really agree with that. I need to reach out to them. I need to work with this person.”

I don’t run ads. I don’t have a PR firm.

And yet, the exact type of person I want to work with shows up in my inbox on a daily, or at least weekly basis. How they found themselves writing me an email wasn’t because I tricked them into a funnel, or I had someone else talk about how great I am. They reached out to me because of pieces like this, where I shared 1) what I know, and 2) how I learned it—and the message resonated with them.

I’ve been shouting these things from the rooftops since Day 1:

  1. If you only focus on how much you can give, you never have to worry about who takes and doesn’t give back.
  2. There is no sense in debating the strategy of something unless the ship is already moving (“You can’t steer a stationary ship”).
  3. You are both what you say you are — and what you do on a daily basis.

Becoming a thought leader, working with the people you truly want to work with, attracting an audience, attracting the right kind of attention, even building a business around yourself isn’t rocket science.

It’s just, in order to do it well, you have to be willing to do 3 things most human beings struggle to do in their everyday lives:

  1. Focus on giving more than worrying about who is going to take and not give back.
  2. Trust the process and get to work before you fully understand the destination.
  3. Do it on a regular (daily) basis.

That’s it.

You don’t need standup

Notice: Below represents PERSONAL beliefs of palmerj3 (Engineering lead at Spotify) about agile and team organization. Your results may vary.

I recently became a technical product manager at work and this puts me in charge of a team of engineers for the first time. Up until January I was a developer who was upset at how many meetings I had.

So I ran an experiment for the last six months which consisted of a few new behaviors:

  1. No stand-ups
  2. No planning at regular intervals
  3. No retros
  4. All meetings are optional

This may sound extreme. But there is some logic to this madness.

I wanted the team to know I trusted them. To know that it’s ok to tackle tech debt, explore, and work at their own pace. I laid out the goals for the quarter and trusted that the work would get done. Then I got the fuck out of the way.

Would you believe it: work got done. A lot of it.

We were an extremely productive team that responded to change and nailed every goal we set out to.

But before we go into detail about why this experiment worked, let’s see how a typical agile team operates.

A typical agile team

We’re going to create a fictitious team called the SuperAgileRockstars.

SuperAgileRockstars do weekly sprints.

So every Monday they spend an hour planning the work for the week. They meet every morning at 10am for standup where each team member says what they did yesterday, what they are doing today, if tasks are blocked, and give announcements. At the end of the week they spend an hour doing a retrospective where they discuss what went right, what went wrong, and create tasks to address these issues.

It sounds pretty logical, right?

How can this paradise of productivity be broken? Let’s see.

  1. Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t. As the team grows this becomes even more complicated.
  2. Stand-ups ENCOURAGE plans to change daily. Lack of consistency is a great way to ruin developer flow.
  3. Standup forces every team member to be productive at a set place and a set time
  4. Extroverts thrive at stand-ups, planning, and retros. It’s no wonder that tech debt is such a common problem. Developers shouldn’t have to PUSH for tech debt to be addressed. Teams should operate at a sustainable pace.
  5. Why do we encourage problems to be discussed once a week? We should address them immediately, not just at retros.
  6. Sprints encourage iterative development. This sounds really good to people like me who strongly advocate small, concise, pull requests over long-living feature branches. But it’s not the same thing. Sprints encourage features over tech debt. How often have you had to advocate spending an entire sprint tackling tech debt?

What would happen if we didn’t plan every week, didn’t do retros, and didn’t do standup?

Stop doing standup

Standup has always bothered me. It usually serves to interrupt developers, make them feel pressured to prioritize features over tech debt, and has been known to last longer than 1/2 hour.

The natural side effects of not doing standup are:

  1. Developers communicate more
  2. Your team becomes more remote-friendly
  3. Tech debt gets addressed
  4. Developers feel more in control and less stressed
  5. Developers know you trust them and that you have their back

At Spotify my role is a technical product manager. It’s my role to “steer the ship” (e.g. decide what we work on). If I’m changing my mind about this on a daily basis that’s problematic. If the entire organization changes its mind on a daily basis then it’s my job to fix that.

The reality is: I’ve told my bosses what we’ll deliver by the end of the quarter and I would rather trust that my team know what’s required to get there and be creative along the way.

I want to give them as much freedom as possible to get shit done.

Feel like taking a day off to work on open source? Fuck yeah.

Feel like working on something completely different for a few days? Have fun.

Think our tech debt is out of hand so you want to spend some time fixing it up? We are best friends now.

I know you’re going to get us to our goals and who am I to tell you every single day, “well the highest priority item on the backlog is x,y,z”.

Fuck that noise.

Stop planning every sprint

Planning on a regular basis is another thing that has always bothered me. It’s rare, in my experience, that things change so drastically that the entire team needs to get together and figure things out. But if there is an emergency then by all means call a meeting and communicate that shit. That said, I’m not against planning, I’m against planning on an interval.

So what do things look like if we don’t plan every week or two:

  1. Developers are trusted to be working on the correct things
  2. Developers aren’t interrupted nearly as much so things get done
  3. Backlog is used as a priority queue of work to be done
  4. Tasks are added to the backlog as needed, continuously
  5. Blockers are communicated right away
  6. Planning happens when plans change. Meeting fatigue is reduced and the team knows this was a last resort and is important

Stop doing retros

Say you’re in a relationship and it’s going amazing. You should totally start going to couples therapy once a week, right?

Of course not. So why the fuck are we doing retros every week or every month?

Furthermore, why are we waiting until retros to discuss problems or to give praise?

What do things look like when we stop doing retros:

  1. Developers aren’t interrupted and get shit done
  2. Problems are addressed sooner
  3. Stickies and sharpies are returned and we buy lunch instead

Here’s some questions I know you’re wanting to ask

“How will I know what to work on?”

Good: Pick an item from the backlog.

Better: The backlog is prioritized and you pick the highest priority item from the backlog.

Best: You work on tech debt or open source because you need a mental health day.

“What do I do if I’m blocked?”

Good: Pick a different item from the backlog.

Better: Create a “blocked” column in trello, move the task there, then pick a different item from the backlog.

Best: Put the task in the “blocked” column, pick a different item from the backlog, and drop a message in slack letting the team know it’s blocked.

“How will I track the progress?”

Good: Ask the team. Don’t ask every day.

Better: Keep the backlog up-to-date & relevant. Fucking look at Trello.

Best: Communicate to the team if anything high priority is happening. Otherwise trust that work is getting done until that trust is broken. Casually get updates every so often over lunch and/or beers.

“Hold on. We totally handle tech debt and we do stand-ups!”

Awesome!

You must have vocal developers who are willing to push for tech debt to be addressed and management that deeply cares about engineering quality.

The reality is that most companies don’t operate this way and even your company is likely not a great environment for introverts.

Conclusion

Effective teams question everything. They also trust each other. They also get a lot of shit done.

This article is my attempt to question what’s become the default behavior of agile teams. Daily stand-ups, weekly/bi-weekly planning, and weekly/bi-weekly retros. We didn’t even discuss estimation either.

My advice for all teams is to not start by complicating things.

Stand-ups, planning, and retros are a tool and you should be putting a lot of thought into what tools you use.

How To Become a DevOps Engineer In Six Months or Less

“Empty highway road in through a colorful desert” by Johannes Plenio on Unsplash

NOTE: This is Part 1 of a multi-part series.

Part 2 is here.

Target Audience

Are you a developer looking to shift your career towards a more DevOps model?

Are you are a classically trained Ops person and you would like to get a feeling of what this whole DevOps thing is all about?

Or are you neither, and simply looking for a career change and have no idea where to start? If so, read on!

Finally, if you have been doing this DevOps thing for years now, you might still find this useful as a validation of where we are and where this is going.

What’s This, Now?

First, what is DevOps?

You can google the definitions and wade through all that buzzword extravaganza but know that most are embarrassingly long word salads stuffed into giant run-on sentences. (See what I did here?)

So, I’ll save you the clicks and distill it down:

DevOps is a way to deliver software with shared pain and responsibility.

That’s it.

OK, but what does that mean?

It means that traditionally, the developers (people who create software) had incentives that were vastly different from operations (people who run software.)

For example, as a developer, I want to create as many new features as fast as possible. After all, this is my job and that’s what customers demand!

However, if I’m an ops person, then I want as few new features as possible because every new feature is a change and change is risky.

As a result of this misalignment of incentives, DevOps was born.

DevOps attempts to fuse development and operations (DevOps, get it?) into one group. The idea is that one group will now share both the pain and the responsibility (and presumably, the rewards) of creating, deploying, and generating revenue from customer-facing software.

Now, purists will tell you know that there is no such thing as a “DevOps Engineer”. “DevOps is a culture, not a role,” they will tell you.

Yeah, yeah. They are technically correct (the worst kind of correct!) but as it so often happens, the term has morphed beyond its original meaning.

Now, being a DevOps Engineer is something like “Systems Engineer 2.0.”

In other words, somebody who understands the Software Development Lifecycle and brings software engineering tools and processes to solve classic operations challenges.

DevOps ultimately means building digital pipelines that take code from a developer’s laptop all the way to revenue generating prod awesomeness!

That’s what it’s all about!

Also note that as a career choice, the whole DevOps space is highly compensated, with almost every company either “doing DevOps” or claiming to do so.

Regardless of where the companies are, the overall DevOps job opportunities are plentiful, offering fun, meaningful employment for years to come.

NOTE: Be wary of companies hiring for a “DevOps team” or a “DevOps department.” Strictly speaking, such things should not exist because ultimately, DevOps is all about the culture and a way of delivering sofware, not a new team or department to be staffed up.

Disclaimer

Now, let’s put the glass of Kool-Aid aside for a moment and consider the following.

Have you heard the old adage, “there are no junior DevOps engineers?”

If not, please know it is a popular trope on Reddit and StackOverflow. But what does that mean?

Simply put, it means that it takes many years of experience, combined with a solid understanding of tools, to eventually become a truly effective Senior DevOps practitioner. And sadly, there is no shortcut for experience.

So, this is not an attempt to cheat the system — I don’t think that’s actually possible to pretend to be a Senior DevOps Engineer with a few months of experience. Solid understanding of the rapidly changing tools and methodologies takes years to master and there is no getting around that.

However! There is a roughly agreed upon (trendy, if you will) menu of tools and concepts that most companies use and that is what the article is all about!

Again, tools are different from skills, so while you are learning the tools, make sure you don’t neglect your skills (interviewing, networking, written communication, troubleshooting, etc.)

Most importantly, don’t lose track of what we are after — building a fully automated digital pipeline that takes ideas and turns them into revenue generating pieces of code.

That is the single, most important take-away from this entire article!

Enough Talk, Where Do I Start?

Below is your roadmap.

Master the following and you can safely and honestly call yourself a DevOps Engineer! Or a Cloud Engineer if you detest the “DevOps” title.

The map below represents mine (and probably the majority of folks working in this space) idea of what a competent DevOps Engineer should know. That said, it is only an opinion and there will certainly be dissenting voices. That is OK! We are not after perfection here, we are after a solid foundation upon which to build.

NOTE: You are meant to traverse this breadth-first, layer by layer. Start (and continue!) with the foundation first. Learn the technologies in blue first (Linux|Python|AWS), then if time permits or job market demands, go after the purple stuff (Golang|Google Cloud).

DevOps Foundational Knowledge

Again, go after the first layer in every pillar. Then, time permitting, go after the second layer to add depth to your expertise.

Once you have the Foundation layer reasonably figured out, move onto the real-world set of skills:

Real-world skills

NOTE: What’s notably missing from the pipeline above is Test. That’s intentional — writing unit, integration, and acceptance tests is not easy and traditionally falls on the shoulders of developers. The “Test” phase omission is intentional, since the goal of this roadmap is rapid intake of new skills and tools. Lack of testing expertise is judged by the author to be an insignificant barrier to a proper DevOps employment.

Also, please remember, we are not after learning a whole bunch of unrelated techno-babble here. We are after a solid understanding of tools that taken together, tell a single, coherent story.

That story is end-to-end process automation — a digital pipeline that moves bits around in an assembly line-like fashion.

Moreover, you don’t want to learn a bunch of tools and stop. Tools change rapidly, concepts much less so. Therefore, what you want to do is use the tools as learning proxies for the higher level concepts.

OK, let’s dig in a little deeper!

Foundational Knowledge

Under the top line labeled “Foundation” you will see the skills that every DevOps Engineer must master.

Here, you will see three industry-dominant pillars: operating system, programming language, public cloud. These things are not going to be something that you can learn really quickly, check them off the list and move on. These are going to be skills that you must acquire and keep sharp on a continuous basis, to stay relevant and up to date with what is going on.

Let’s go through them one by one.

Linux: where everything runs. Now, can you be an awesome DevOps practitioner and stay entirely within the Microsoft ecosystem? Of course, you can! There’s no law that mandates Linux for everything.

However! Please know that while all the DevOps-y things can certainly be done with Windows, it is far more painful and the job opportunities are far fewer. For now, you can safely assume that one cannot become a true DevOps professional without knowing Linux. Therefore, Linux is what you must learn and keep learning.

Honestly, the best way to do it is to just install Linux (Fedora or Ubuntu) at home and use that as much as you can. You will break things, you will get stuck and then you will have to fix it all and in the process, you will learn Linux!

For reference, in North America, the Red Hat variants are more prevalent. Therefore, it makes sense to start with Fedora or CentOS. If you are wondering whether you should get the KDE or Gnome edition, get KDE. That’s what Linus Torvalds uses. 🙂

Python: the dominant back-end language these days. Easy to get started with, widely used. Bonus: Python is very prevalent in the AI/Machine Learning space, so if you ever want to transition to yet another hot field, you’ll be all set!

Amazon Web Services: Once again, it is impossible to become a seasoned DevOps professional without a solid understanding of how a public cloud works. And if knowledge of a cloud is what you are after, Amazon Web Services is the dominant player in this space, offering the richest set of tools to work with.

Is it possible to start with Google Cloud or Azure instead? Absolutely! But we are after the biggest bang for the buck here, so AWS is the safest play to make, at least in 2018.

You get a free tier to play with when you sign up for an account at AWS, so that is a good place to start.

Now, when you log into the AWS console, you are greeted with a simple, easy to understand menu of choices.

“Discovering yet another AWS feature I never knew about” by Tom Pumford on Unsplash

That was sarcasm. Good news is, you don’t need to know every single Amazon tech.

Start with the following: VPC, EC2, IAM, S3, CloudWatch, ELB (under the EC2 umbrella), and Security Groups. These things are plenty to get you started and every modern, cloud-enabled enterprise will be using these tools heavily.

AWS’ own training website is a good place to start.

I recommend you set aside 20–30 minutes daily to practice Python, Linux, and AWS.

NOTE: this will be in addition to the other stuff you will have to learn. Altogether, I estimate that spending an hour daily, five times a week is enough to give you a solid understanding of what is going on in the DevOps space within 6 months or less.

That’s it for the Foundational Layer!

In the subsequent articles, we will explore the next level of complexity: how to Configure, Version, Package, Deploy, Run, and Monitor software in a fully automated way!