• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Dion Almaer

Software, Development, Products

  • @dalmaer
  • LinkedIn
  • Medium
  • RSS
  • Show Search
Hide Search

Engineering Mangement

Wife Swap? Role Swap!

November 19, 2015 Leave a Comment


In the world of management your job is partially to build the team that builds the things. As an engineering manager, I sometimes find myself thinking:

“Man, dealing with computers…. so nice. So rational.”

People are complex and predictably irrational. Fortunately, I actually like people and find the challenge of helping teams a rewarding one, even if there are some days that I come home quite pensive.

While asleep my brain is off trying to find patterns, and this act leads to connections such as comparing how teams are related to each other and their behavior and how families are structured.

When it comes to these, and peer-to-peer dynamics, one root cause is often a lack of empathy and a slew of assumptions that your brain has created in order to try to understand the complex world around it. This leads me to think “man, if they could walk in each others shoes for a day….” from time to time, and I wonder why we don’t do more to make that happen?

Some companies do a good job of having shadowing programs, moving people around so culture and knowledge can be shared, and experience can be gained. It also happens organically, as people naturally move about. But would it make sense to do this much more regularly?

I have seen the need in a few situations:

Understanding another role

It isn’t always easy to understand the trials and tribulations of someone in a very different field, or in a different role. It is easy for us to think that what we do is hard and complex (as we know about the complexities) whereas their work seems easy (as we see the output vs. the toil and training that went into it).

This also can become an issue if there are roles where people feel like more input is directed at them, and they can’t give the same level of input back. My typical example here is the engineer and the designer. A designer on my team once complained that it wasn’t fair that the engineer was giving so much feedback on their wires. They felt like they were the expert and that “I can’t do a code review and give feedback there!” That was the real issue, the perceived asymmetry. Since we are all users of computing platforms, many of us feel like we have opinions on the UX of a product that we are building. That doesn’t mean that we have the same level of deep understanding of a UX expert though, which is why they are responsible for the experience. That responsibility does NOT mean their job is to come up with all the ideas though, which is why a good UXer will listen to all and look for good things they have missed.

Also, although you may not be capable of a code review, you can review the engineering. You can look for crashes, UX bugs, jank, etc. That is very much in scope, so in reality you can have a lot of feedback back to engineering.

Understanding another team

The same notion of “I understand the complexity and only see your output” also kicks in with teams. From the outside it is easy to think that another team is under performing based on your assumptions. This doesn’t mean that they are NOT under performing of course, and it may be that this is a team that you know well, and have a deep understanding of their domain, but it isn’t always the case.

This can often happen between the “business” and “product development” worlds. The business naturally wants features and functionality and often tends to wonder why its so hard to get those screens up and running! They can also easily run into “I saw them do screen A in a day, so why is screen B taking a month!” when the complexity differences are huge. If the misunderstanding is this far off though, then the product development team isn’t doing a good enough job at explaining what they are doing 🙂

Understanding at another level in the chain

The pointy hair boss. What a moron. He has the easy job at the top! Why doesn’t he always do thinks that I want him to do? Our strategy is dumb and “if I was in charge….”. I admit to meeting plenty of pointy haired bosses, but it turns out that it isn’t as fun up there as you imagine it is. They have to manage multiple teams with complex priorities and unclear answers.

You know your area of the org deeply, but take a minute to think about what is going on in the other parts of the org, or in other parts of the company. Do you understand the strategy? Do you think you have a good handle on the context? If not you should get it from management, and it is poor form if they haven’t pushed it down to you. You can’t be expected to make the best decisions if you don’t have the context.

It is for these reasons that I think it is wise to think about how to keep organizations a little more dynamic. Change is constant these days more than ever so why not embrace it and think about how to use it to dispel some tension and gain shared understanding?

You have too many job levels!

June 10, 2015 Leave a Comment

So much easier when you have points and simple metrics to define your s/class/job!

Data is great, but whenever you see data being applied to areas that you can’t easily measure then it feels like it is a recipe for trouble as the room to distort is abundant.

There are many fields like this but have you noticed how this happens in spades in HR (or “People Ops cos we are talking about people not RESOURCES”)?

At most companies with a sizable employee base you find The Levels. I am filled with dread as I open up the excel spreadsheet that defines each of the degrees of various professions. It is extremely rare that there aren’t far too many stratifications.

Where else do we see the notion of levels? Martial arts are the prototypical examples. As a practitioner you climb up the ranks with hard work and by proving yourself mastering and demonstrating your proficiency. In many of these practices it can be somewhat clear what to master, but even so it isn’t an exact science.

Helen may be able to beat John in 2 out of 3 bouts, but Frank tends to beat Helen even though he can’t handle John.

Also, martial arts and the levels are not just about combat. Whoever defines the level requirements ends up setting the incentive structure and thus defining the type of martial artist they are moulding.

“I have a black belt!”

This phrase is right up there with: “I ran a marathon”. It is a sentence that tells you something about a person. With the marathon runner you know they put a lot of effort into getting their fitness level to push their body over 26 miles. Sure, they may have done the race that didn’t have any hills and with good weather, but even the best case is an accomplishment.

With martial arts it isn’t quite as simple. I doubt that someone had an easy path to black belt, but the milestone differs by a wide margin. I enjoyed Karate as a kid, and have also seen martial arts through the eyes of a parent. A black belt for me was at least a 10 year odyssey, but at some of the dojos they give out belts like candy. I get it: “if we keep giving out belts kids will like it and keep coming (and paying)”.

Should you be able to “test out” and jump to a particular belt if you studied all of the requirements? Or, is the journey part and parcel of climbing the levels? There are many intangibles such as building the relationships with fellow students and instructors.

Can you quantify the value that a job role or a person brings to a business? It is very very hard indeed. There is so much context and external forces (Frank, an engineer, builds a tool that delivers some value, but his profession puts pressure on the salary required to keep him!)

The reality is that compensation is not fair for everyone at your company. The process was never setup correctly to begin with and it has changed constantly over time. Some would gain from that, and some would lose. In the era of acqui-hires, a distortion effect happens where peers doing the same work (but who came in the front door) don’t get the same rewards. While it can be a good lighter fluid to bring in talented people this way, you shouldn’t ignore the negative side effects. You have to ask yourself: if they wouldn’t join the mission as an employee, are they right for us? Are we taking care of our core employees? Are we building a great base to smooth out the distortion?

As a society we tend to have shorter and shorter stints at a job. Executives are also getting paid (proportionately) more and more. Add this to the nature of public markets, and are we not building the incentives for an incredibly short term culture? We may trick ourselves into thinking “it isn’t short term thinking, I am just trying to get shit done!” but I have made many mistakes in judgement by taking an easy short term approach. One reason why “still having the founder” can seem to matter so much to great companies is that they are there to think long term. They aren’t thinking about how “if we can just make it a couple more years we can cash in on our huge executive salary!”

Back to the insane number of job levels. These quickly show employees how unfair compensation is. If there are 13 engineering levels (I have seen this before!) with a large number of engineers, then it is pretty simple to find someone around you who is above you in level but not competency (especially in your biased opinion).

If you are struggling to define the differentiations between levels then you have too many. Matt Briggs has a fantastic article on the role of a senior developer which clearly articulates some differences:

A good junior developer can be given a known task, and be expected to execute it quickly, and well.

A good intermediate developer needs less supervision. They can be trusted to raise issues of code design, and play a valuable role in design discussions. They are also the “workhorses” of the dev team. However, further mentoring and higher level supervision is still vital.

A senior developer is intimately familiar with their own failure. They have written code both under, and over designed, and have seen both fail. They are reflective about the things that they do, evaluating their successes and failures when approaching problems with intellectual honesty. A senior developer has fallen out of love of the complexity which dominates the intermediate, and is obsessed with simplicity.

If you haven’t done this thinking and laid it out for all of the engineers then you aren’t done.

This exercise also allows you to separate various needs, such as:

  • How do you handle compensation?
  • How do you make it clear who owns particular decisions?
  • How are the management and individual track different? (please don’t conflate them!)
  • How are we helping our engineers get better at their craft?

It will help you with the hiring process too. The obvious question is: “How should our process work to know if someone is at a particular level?”

You may surprise yourself with the conclusions: “You know what, it has been really hard to get this right. Instead what if we slot people after we have hired them and they have spent time with us?” This is a trade off too, as it means you can’t be as clear and you risk pissing people off if they think they should be more senior than the slotting process found them. There is a constant battle between clarity vs. doing the right thing and the reality that we don’t have enough information up front and this sets people up based on too much luck. This realization may also have you setup the right levers so you can move people around as you find out you are wrong.

At a larger company the leveling can far too often be relative to the group vs. the organization. This happens with performance reviews in spades. If you have ever had to deal with the pain of stack ranking then you know how frustrating it can be. Let’s say you are on a small team with high talent density. You know that a weaker team elsewhere with a poor leader is rating their folks high, but your team with strong expectations blows them all away, yet rates lower.

I have gotten a real appreciation for organizations and setting up the right incentives and tools. In a startup you can wing it so much more, but that is much easier than solving at a bit of scale (truly a small number of people).

I think it will be increasingly important to define the parameters and values, and arm people with the right tools to offer a flexible career path at their job. Expose the trade offs to the entire team and let them be part of the process. Focus on areas such as role clarify vs. too much process in the wrong places. Somethings will not change much over time as they are tied to the company values. Other solutions are solving temporal problems and should be clearly marked as such so the team can understand the why not just the what.

Primary Sidebar

Twitter

My Tweets

Recent Posts

  • I have scissors all over my house
  • GenAI: Lessons working with LLMs
  • Generative AI: It’s Time to Get Into First Gear
  • Developer Docs + GenAI = ❤️
  • We keep confusing efficacy for effectiveness

Follow

  • LinkedIn
  • Medium
  • RSS
  • Twitter

Tags

3d Touch 2016 Active Recall Adaptive Design Agile Amazon Echo Android Android Development Apple Application Apps Artificial Intelligence Autocorrect blog Bots Brain Calendar Career Advice Cloud Computing Coding Cognitive Bias Commerce Communication Companies Conference Consciousness Cooking Cricket Cross Platform Deadline Delivery Design Desktop Developer Advocacy Developer Experience Developer Platform Developer Productivity Developer Relations Developers Developer Tools Development Distributed Teams Documentation DX Ecosystem Education Energy Engineering Engineering Mangement Entrepreneurship Exercise Family Fitness Founders Future GenAI Gender Equality Google Google Developer Google IO Habits Health HR Integrations JavaScript Jobs Jquery Kids Stories Kotlin Language Leadership Learning Lottery Machine Learning Management Messaging Metrics Micro Learning Microservices Microsoft Mobile Mobile App Development Mobile Apps Mobile Web Moving On NPM Open Source Organization Organization Design Pair Programming Paren Parenting Path Performance Platform Platform Thinking Politics Product Design Product Development Productivity Product Management Product Metrics Programming Progress Progressive Enhancement Progressive Web App Project Management Psychology Push Notifications pwa QA Rails React Reactive Remix Remote Working Resilience Ruby on Rails Screentime Self Improvement Service Worker Sharing Economy Shipping Shopify Short Story Silicon Valley Slack Software Software Development Spaced Repetition Speaking Startup Steve Jobs Study Teaching Team Building Tech Tech Ecosystems Technical Writing Technology Tools Transportation TV Series Twitter Typescript Uber UI Unknown User Experience User Testing UX vitals Voice Walmart Web Web Components Web Development Web Extensions Web Frameworks Web Performance Web Platform WWDC Yarn

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

  • February 2023
  • January 2023
  • September 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • November 2021
  • August 2021
  • July 2021
  • February 2021
  • January 2021
  • May 2020
  • April 2020
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • April 2019
  • March 2019
  • January 2019
  • October 2018
  • August 2018
  • July 2018
  • May 2018
  • February 2018
  • December 2017
  • November 2017
  • September 2017
  • August 2017
  • July 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012

Search

Subscribe

RSS feed RSS - Posts

The right thing to do, is the right thing to do.

The right thing to do, is the right thing to do.

Dion Almaer

Copyright © 2023 · Log in

 

Loading Comments...