Why Did I Start This Blog?

Software engineers spend a good part of their day writing. Whether it's design specifications, API documentation, functional requirements, email, instant messages or <gasp>code</gasp>, the number one most important tool of our trade sits between our fingers and our blank screens. While not a writer like Charles Dickens or Sir Arthur Conan Doyle, all of us write for a living. Our writing looks a little funny to anyone that hasn't learned to translate it, but in the end if I were blogging in Klingon that would look a little bit funny too.

I'd been meaning to get back into the habit of blogging for quite some time, and this guy named John Sonmez came along and gave me a push.  In all honesty, he didn't even realize he'd done it, because it was really someone at a super senior level in my company that told me to read John's Book.  When I did, I also started following John around on Twitter, and to my appreciation, he actually writes back when you have questions for him!  He pointed me to his web site (http://simpleprogrammer.com/) and his blog course, (http://devcareerboost.com/blog-course/), both of which I've actively engaged with since I discovered them.

Having a blog has allowed me to express the things I'm most passionate about as a software engineer.  While you won't find any posts from me about bit twiddling or the coolest AngularJS animation ever, you will find something that most other guys tend not to talk about - money (and other business/leadership/<please make it stop> things.)

Because my majors in college had both a technical focus on the computer science side, and a business focus on the business administration side, I often act as a translator between the C-level and V-level employees at a given company, and the general engineering staff. I've learned a few things while I do that, things like how to impact ROI and how to talk about opportunity cost. While most engineers have an inherent understanding of what these things mean, I personally feel like most also don't want to take the time to try to make their otherwise busy lives also make "money" sense to the people that hired them. For most engineers I know, once the "hiring" game is over, they tend to just stick to technical problems and leave career advancement to the next time they jump a job. Most of this can be better understood in my blog throughout - but I also wanted to make it clear why I write. I write because I love the topic I write about, so I rarely find myself at a loss for what to put into the blogosphere.

I appreciate John giving me the push (sometimes more than once) that I need to keep this blog alive. And I appreciate everyone who reads my blog, because it makes me feel like what I say means something to someone besides me.

How Do I Know My Work Matters?

If you follow me around the internet (twitter, amongst other things) you will eventually see that I really appreciate the book Team Geek. One of the core themes running through the book focuses on how to keep your team motivated and engaged. They concentrate on the concepts of autonomy, mastery, and purpose. In this post I want to focus on my understanding of purpose.

Autonomy and mastery deserve a fair amount of writing, too - but not right now.

If you have read previous posts you know how important I find goal setting - when done for the right reasons. This kind of goal setting should reflect the deeper purpose for the work you have assigned. As long as this is the case, at least to some degree you have the ability to convert your goals into quantifiable and measurable outcomes. The guys over at Etsy sure do. In fact, the kind of measuring Etsy takes so seriously even brings rise to whole software solutions like New Relic.

I mention all of these things because they all lead up to a concept that I feel CEOs and CFOs really like to focus on: KPI (key performance indicators). If you want to talk to your boss about getting your company to spend more money on your work, one of the key things that you can do is show how the work you do has improved some KPI values. For a practical example, success in my current role depends heavily on the speed at which our application responds to user requests. We will use the New Relic solution to report on response times, and if they are not within the accepted threshold I personally take a decent financial hit. Our customers want fast, most of them said so directly. So it makes sense to closely monitor performance and generate incentives accordingly.

Application performance is most definitely a KPI at my job. So we'll measure its health any way we can.  Once you can clearly measure the right things, then you can build strategies for how to impact their value. Once you have evidence that the changes your code make impacts KPI in the right direction, you have another important TLA (three letter acronym) to talk about with your boss: ROI (return on investment). Often we're not in a position that ROI has a tangible and measurable quantity. In another post I'll talk a bit more about ROI that isn't measurable. In this one ROI should show in the trends in KPI, specifically related to the work you have done.

In a development environment that supports rapid deployments, it should not provide challenging to make a small code change and see how KPI change. So, make sure you check in code that gets tied to KPI positively. Then you know your work has purpose, and you also have a compelling reason to ask for more money.

So, You Want a Promotion?

There's a better than average chance that you spend a good bit of time thinking about programming techniques, best practices, and otherwise how to be the best coder you can. There's also a better than average chance that you feel like you should possibly have a stronger title (and associated paycheck) than you do now because you are so passionate about the work that you do. I mean, you could probably even point to the technical blog that you keep about the <insert highly specific but important topic here>.

So, how come your boss hasn't come into your cubicle waving a wad of cash and a business card with "Vice President of Awesome" on it? Well, probably because your company doesn't pay for "Awesome". They might pay for "Incredible" or "Wowza," but "Awesome" just may not fit into the company's core competencies, mission, and overall strategy. The first step into getting a promotion is to find out that you actually want to climb the ladder for the company you work for. You need to have clearly defined goals for yourself, professionally - otherwise getting promoted won't really get you anything you really have purpose for.

Sometimes the only available options for promotion within an organization mean moving into a position you have no desire to participate in. After all, software engineering and Management of software engineering are two entirely separate disciplines. Related, yes - relying on the same kinds of skills - definitely not.  Find a guy or gal who got promoted to management who once wrote code, and ask if management is anything like writing code. I imagine you'll get back some amusing anecdotes proving just how different they really are. If you have a strong passion for daily having your hands in your BitBucket/Github/SourceSafe (oh, wait...) commits, then you don't want to get promoted into engineering management. Managers don't commit code. Managers that I've worked with rarely even review committed code. And that's OK, if you're interested in forming department strategy, and staffing levels, and development process reformation, etc. etc. But if you just really love writing Groovy/JavaScript/Ruby/C#/Python/whatever - management probably isn't for you. And if you work some place where there's not a promotion path for senior level engineering, you need to do two things.

1. Have an honest conversation with your supervisor about your long term career expectations. Transparency is key in every business environment. Be careful if you have a toxic boss, though.
2. Start the search for a place that has a clear promotion path for people who write code every day, all day. Places like that exist, and super-senior engineers are in very high demand these days.

Assuming this isn't the case, and you've already succeeded in finding a clear promotion path for yourself as an engineer, and you're very clear about what your personal career goals are - the next step is open and honest communication with your superior at work. As I was defining my goals for the year at work, I told my boss that I intended on becoming the Lead Architect for our team. So we wrote that down as a tangible (and financially rewardable) goal that by the end of the year (beginning of 2016) I'd have a promotion pending into this new position.

The key to getting a promotion is upward management. You should not assume that a promotion will be handed to you if you haven't explicitly been working towards it. Your manager has to have the time to find a replacement for whatever position you'll vacate upon your promotion. And your manager will also have to work with other key members of your organization to train and prepare you for a position that requires further responsibility. All throughout the period you're being considered for a promotion, your manager has the responsibility to assure you can handle the new role.

The clearest path to becoming promoted is to start acting as if you already have been - but don't expect your company to pay you for assuming more responsibility just because you feel like you deserve it. Once you've proven to yourself you can handle the bump up the ladder, the next step is to prove it to the managers that decide you have earned it. Keep track of what you're doing and how you're doing it. Listen to suggestions from your management about how to course correct. And above all, make sure that your manager agrees that your promotion is best for the goals of the company (remember, you've already confirmed with your personal mission statement it's best for you) - because then you'll have your manager holding up the ladder as you climb it.

What's On Your Mind?

Keeping track of everything going on at work (or at home) which involves me using my brain sometimes gets overwhelming and disorganized. Without a good tool to help me make sense of everything I'm doing, I'd likely end up just sitting in a corner somewhere playing Settlers of Catan or 2048 on my smartphone. Speaking of which, I do use my smartphone for helping keep all of my thinking organized. It's not the tool I use first, but if I can't get to a computer that lets me run XMind my smartphone is my second choice, I use SimpleMind Free.

Mind mapping for me helps me concentrate and organize my thinking. Because it's freeing to use a mind map and just start putting ideas on the screen without worrying about where they fit into the big picture, ideas tend to flow pretty freely. I even just made a mind map about this blog because I realized it would probably help keep me organized if I did so. Here it is:

I don't ever really think of a map as finished.

Since maps are so easy to add to and reorganize they help me to remember things I've forgotten about and to find things to think about that I may not have originally considered. Very rarely do I have a mind map open on my screen where I'm not adding new relationships to it, adding new topics to it, or otherwise organizing it in a way that works better than it did for me the last time I looked at the map.

The nicest thing about a mind map is that you don't have to share it with anyone. It can belong to you, and take on a life that means something important to your own internal dialogue.  Don't get me wrong, once my maps get into a state where they're somewhat well organized, I tend to share them with my colleagues to get further feedback and input so we can make sure we don't miss anything as a team. And, in general - this kind of diagram is something most everyone understands pretty intuitively without much explanation. However, sometimes I add icons to my diagrams that aren't immediately obvious. I add a helpful key explaining what I mean when I do that.

I'm happy to take input about other things that need to go on the map for this blog.  Feel free to leave me a comment if you have further ideas about what to write, or even larger "topic groups" that you may have in mind. I could write many posts about many things related to engineering in business because I'm so passionate about it, but I also like to know what others find interesting or helpful. Don't hesitate to let me know what's on your mind!

Do You Have a Minute?

There's a question I get asked frequently that carries quite a bit of weight. When a colleague asks me "Do you have a minute?" it means a few great things to me.

1. They are having some consideration and mutual respect for me, not demanding my time but asking for it.
2. With as busy as almost all of us on the team are, we make sure to take time to help one another and listen to one another. Though certainly not the only profession where learning is a critical aspect, it's most definitely a career in which we spend as much or more time learning than doing. It's much easier to have a career based in learning when all of your colleagues make time for you.
3. It reaffirms that I provide value to the team. If someone needs my input, usually I do my best to make my input as valuable as possible.  It's a tiny confidence boost to know someone wants my attention.
4. Sometimes the situation requires more than just a minute. Sometimes I have to make a point of setting aside a block of time for helping a team mate. Much of the time I am helping teach junior team members best practices and programming patterns. I think this is a critical path to mastery. It's much easier to teach a subject you have familiarity with than one you are new to.

I make it a point to help out when my team needs me. I may not be available immediately every time I'm asked, but I do always find the person who asked as soon as I can. There's a difference between having time and making time. I make time for having a minute. These are some of the most important minutes of my career.