InRhythm

Your partners in accelerated digital transformation

Jack Tarantino

On the subject of Leadership vs Management

In a business environment, there is a huge difference between a leader and a manager. In many circumstances and in many companies these two terms are conflated and treated similarly. Arguably, I believe they are different and should not be performed by the same person (if your organization is large enough, that is. At a startup you cannot afford one person per role).

An important component in understanding the difference between leadership and management is to understand that these are responsibilities, not roles or titles. One’s title can be anything. My business card could say “Lead Software Engineer” or “Code Monkey Level 3,” but it does not change what my actual work and responsibilities are. Similarly, a responsibility is not the same as a role. Two people that have “Director” in their title could be, and are likely to be, responsible for managing different humans, different budgets, the outcomes of different projects, and in their day-to-day could work on completely different things. In the rest of this article we’ll take a look at the definitions and differences between leadership and management and how they can be applied.

Leadership

I define leadership as having a responsibility for the direction and success of your team. In many, if not most, cases leadership means you are not only responsible for direction and success, but also education. Leaders are responsible for providing growth opportunities and for the success of the project that they are attached to.

From an engineering perspective, “success” may mean that you have a product with zero known bugs and strong test coverage or a streamlined development process so your team can work as effectively as possible. From a product perspective, “success” may mean getting the product to market smoothly, communicating progress with any interested parties, and hitting all your desired/required features.

Leaders are supposed to be at the top of whatever technical chain they’re in. You can find leaders in engineering, product, business, design, and any other career track. This is reflected in how we use phrases like “industry leaders” to describe those who are setting the bar that all the rest of us aspire to grow to. Nobody says “industry managers” … I suppose because that would imply some sort of cabal or oligarchy. You’ll notice that I haven’t talked about employees, their hours, benefits, communication, or anything else related to that. Leaders are not responsible for humans, they are responsible for teams. They are responsible for providing resources to their team but they are not responsible for human needs.

Management

Management is all about the humans. Managers are responsible for making sure that the humans they are charged with are happy, productive, and meeting expectations. People who have management responsibilities tend to be responsible for things like making sure that people get in on time (if your company has a start time), making sure that employees feel good about their job using techniques like one-on-ones, and helping the humans on their team when someone is struggling to meet expectations or struggling to communicate their needs. You may also work on group cohesion or reporting to the rest of the company about your team’s accomplishments. As a manager, your number one priority is the specific humans that you manage.

Company Hierarchies

While personally, I’m a fan of keeping company hierarchies as flat as possible, that’s not always possible or easy to achieve. When it comes to the creation of leadership or management hierarchies, I believe those responsibilities should be delegated to different humans if and when possible. In a recent position, I had two different people serving as my Leader and my Manager. Neither of them had a title that included either of those words, but both understood that from a technical perspective, one would be my guide and the other would manage me from a human/HR perspective. This model worked out fantastically for our team, as we had very well-defined responsibilities instead of just calling one person my “boss” and having that one person be responsible for everything about my worklife. If, in your organization, you can set up separate Leadership and Management chains, I would strongly encourage it. By better defining people’s roles and responsibilities in smaller, more measurable ways you’ll have better communicated your expectations all around and everyone involved should be happier and more productive at their particular responsibilities.

This post is brought to you by InRhythm’s own Jack Tarantino. Check out his blog for more thinking like this.

ES6 IIFEs with fat-arrow functions

Writing Immediately Invoked Function Expressions or IIFEs in ES6(Also known as ES2015) just got a lot easier with the introduction of fat arrow functions.

(global => {
  const MY_CONSTANT = 'api key or something'
  let counter = 0
  let some_array = [1,2,34,5,6,7]

  counter = some_array.reduce (total, item) => total + item
})(window)

This is great. Much shorter than the old ES5 way of writing IIFEs. Or if you don’t need to reference the window/global object and you just hate extra characters:

()=> {
  // code goes here...
}()

I would be hesitant to use this second approach in some cases because it’s not immediately clear that the function is going to be invoked immediately. The containing parens(while not super pretty) let you know from line one that this is a function that will be invoked right away. Also be careful using this in fat arrow functions in general. They have a slightly different context than normal functions which can bite you.

As a bit of extra credit there’s an even shorter way to write IIFEs in ES6 which is to use the block context syntax (not super recommended. there’s a reason you probably haven’t ever seen this before) all on its own like so:

// some code...
{
  // whatever happens here is private and invoked immediately
  console.log("I'm executing code immediately!")
}
// more code...

This approach is very fun because it requires the absolute minimum amount of code. It doesn’t allow us to take/pass arguments though so it’s a bit limited in terms of the features we usually use in IIFEs but that shouldn’t stop you if all you want to do is create a new closure to hide private variables from outside code.

This post originally appeared on Jack of Spades. Check out his more recent writing and follow him on twitter!

On the subject of Learning and Growth

Here at InRhythm, we’re passionate about Learning and Growth. Normally I don’t unnecessarily capitalize words, but that’s the subject of this post and I think it’s important to emphasize those words and what they mean. We define Learning and Growth as the process of becoming a better, more advanced person, capable of handling new and familiar situations more efficiently and effectively. So why are learning and growth so important to us? Because our people want it!

What’s the problem?

Across all industries, but especially in the consulting industry, employee retention is a big issue. Consulting has one of the highest turnover rates of all industries. Historically, a lot of consulting companies have employed a more dog-eat-dog mentality. “We’re in an industry that’s all about the bottom line, so why shouldn’t we treat our employees the same way?” – these companies employ a strategy along the lines of “grow or go,” treating employees like they must either climb the corporate ladder or get out because there’s no room for those who do not aspire to be the CEO. The problem here is that not everybody wants to be a CEO and that is okay.

Employee retention is almost exclusively a function of employee satisfaction. In all cases of turnover (voluntary or involuntary termination), it is due to poor employee satisfaction. Terminations are largely based on performance and there is an established correlation between employee satisfaction, productivity, and retention. Keeping employees happy and productive requires a large investment by employers, but those that have made the commitment find that the return on their investment far exceeds what they invested. Which brings us again to what satisfies employees? How do employers keep them happy?

Broken attempts to fix it…

A lot of people are aware of the correlation between employee satisfaction and employee retention. There are a multitude of issues that could lead to dissatisfaction such as poor management or no trust between coworkers, but I want to focus on learning and growth. I’ve seen many different employers try to make their employees happier but their efforts are usually a little misguided. They try things like snazzing up the office with new decor, mandatory team-building exercises, holiday parties, or just throwing money at the problem and offering people bonuses or incentives. The last one is actually the most problematic. Studies show that once people reach a “comfortable” income level (adjusted for your location) they’re much less concerned about exact dollar amounts and more about their lifestyle. A raise will simply not keep people around as much as getting their own office and/or fixing whatever cultural problem they’re suffering from.

How we address it

We try to give people exactly what they want. Across the board, most people look for jobs to be growth opportunities. They want their position to be something they learn-into and then later something that provides them more contextual and higher-level growth. Very few people, especially in this industry, want to just do what they already know how to do. They want to do something slightly different to keep their brain and their career growing.

“Our people are the most important part of our company. It’s not the budgets, it’s not the office and the toys, it’s not messaging or branding… It’s the people that we work with.”

We try to provide growth in several ways. First, we only take on projects working on modern, interesting tech; our people don’t want to work on legacy apps maintaining code written years ago, they want new stuff where they can stretch their creative muscles. Only taking on modern projects means potentially turning down lucrative projects, but we also have the peace-of-mind that the whole team isn’t going to quit in 2 weeks. We also host a TON of learning events. So far this year we’ve worked on meetups exploring best practices in VueJS, CSS, and UX Design. We get good attendance at these meetups and I think it’s because our people really yearn to learn. We’re also very into finding learning resources for our people. Personally, I make sure to share as much interesting stuff on Slack as I can so that the team can benefit from the same interesting bits that I benefit from. We have a huge bookshelf at the office with books on all sorts of topics: Philosophy, Management, Coding, Interviewing, Business Development…

One of the reasons I joined a consultancy and InRhythm, in particular, is because of the opportunity for learning and growth and I wasn’t disappointed. Since I started here, I’ve been able to work on multiple client sites, learning about different cultures and processes. I’ve been able to work on different JavaScript frameworks that I might not have worked on otherwise. I’ve played different roles in the company and best of all: I’ve been able to spend time with a diverse group of interesting people. This kind of positive experience is easy to reproduce, all you have to do is listen to your people. If they say they want learning and growth, give it to them! If they say they want better snacks or more wall art or the budget to go to a conference, give it to them! Those happy, learning, growing employees will produce more than any others you’ve had before and they’ll stay with the company for a nice long time.

Additional Resources: