Hacker News Reader

Comment by byoung2 | Hacker News Reader

An engineer focuses on the what, where, and how...a leader focuses on the who and why. For example you are considering adding a feature to your app. As an engineer you think of what you need to build how to implement it, where to store the data or put the logic. A manager focuses on why you should or shouldn't build it, who on the team does what part, how much it costs, etc. Imagine the transition from line cook to executive chef...when you're in charge you have to think big picture about menus and marketing and let your team handle the tasks of chopping of vegetables and plating entrees.

View on HN

One of my favorite ways to sum this up is thinking tactically (who and why) vs operationally (what and how).

The third layer on top of all of this is strategic thinking (in theory, what your executive team is providing... even higher level and longer term abstract goals).

Your executive team thinks strategically about what the goal is, your engineering management thinks tactically about the people and tasks needed to complete the goal, your engineer thinks operationally about how to build or design the work in each task.

That's a great way to visualize it. One of the hardest parts about my transition from engineer to director of engineering was planning ahead for headcount without knowing what upper management had in mind 12 months down the line (they didn't know either).

It was a hard part for me as well. How did you approach it? Maybe, you could also share some useful links if you keep them?

nicely explained, thanks!

I think you’re mixing up tactical and operational though. In the standard military vocabulary at least, the operational level of decisionmaking (what) is between strategic (why; the most abstract) and tactical (how; the most concrete).

I was an engineering manager until recently, didn't get much enjoyment out of my role since I had to focus more on whats and whys instead of hows which is what excites my engineering mind. Now I have changed job to an engineering role and having lots of fun building stuff and learning new things. However at times I wonder whether I made the right call, whether my career will stagnate if I am not interested in moving up the org ladder. Make no mistake, I absolutely loved the responsibility and freedom that came with a managerial role, it was just my engineering appetite that was left unsatiated. Is there anyway to keep oneself occupied with technical stuff in a managerial role? Doing your teams work is not the right thing neither for the team nor for the company.

> Is there anyway to keep oneself occupied with technical stuff in a managerial role?

It's been 1.5 years since I transitioned from a Solution Architect role and into a Technical Manager role, and I still struggle to keep myself out of my devops-team's kitchen. I'll still offer advice and direction based upon my past experience, but try to maintain those "teachable moments."

But for me, the only way I could fully scratch that technical itch is to pick up some hobby electronics projects at home.

Ironically, most recently I ended up building an Arduino traffic signal light for the office, interpreting data from our Sensu/Telegraf/New Relic APIs, just to show my team when our servers are struggling. Heh

One thing I have seen some managers do at my company is use their coding skills to help streamline their work, i.e. create scripts to help pull data so they can create charts or query for data to form some analytics to help inform decision making on the right path forward.

I have also seen some still be able to get into the nitty gritty too to help solve problems that are critical & beyond their reports' abilities at the time and to ease the pressure.

+1. Due to the small size of our company, my role still is somewhere between lead engineer and a pure managing position, but it‘s enough of the management schedule that I can no longer be a reliable partner for working on the core product. So I try to automate/optimize internal workflows with my coding skills, i.e., I build tools that improve things if they exist but do not break or block things if they‘re delayed due to too many meetings creeping in.

It's funny but sometimes I feel like I spend as much time doing reporting as someone as when I was entry level. The difference is sometimes my team isn't able to run these reports or I'd rather they focus on other things.

[disclaimer: I haven’t been a people manager for too long, so take it with a grain of salt]

I block off some time each day to do ‘something technical’. Sometimes it’s making something pretty that was ugly before. Sometimes it’s learning a new tool my team is considering to pick up. Generally these are things that are important, but not urgent.

For larger projects, I often attend the design reviews. Sometimes I help on the designs, especially if it’s a new product altogether.

All managers on our team are also required to participate in the on-call rotation.

Between those three, I feel like I am still “in the trenches” enough to not forget what it’s like.

I help write unit tests for code my team is working on. It's fairly non-blocking (we won't slip a delivery date if I get pulled into something else for a few days) but still requires me to understand the code base and ask questions of the engineers.

Do another online MS CS degree from a top school like Georgia Tech, UIUC, UAustin etc. and study everything you ever wanted to know. That should keep the technological fire inside you. As a bonus, you can do iMBA at UIUC in parallel and have both engineering and management covered.

A way to keep yourself occupied? No. You’ll just be interrupted every 5 minutes.

But you can certainly do something small in between.

Even as an engineer I often focus on the ‘why?’, since answering that first prevents me from having to do anything else.

Totally agree -- I too had to learn this the hard way. Also, I wrote this during the difficult period when I myself was transitioning from tech to lead a few years ago. Hope it helps: https://www.linkedin.com/pulse/failure-delegate-pitfall-tran...

Just building on the who and why idea ... as a technical manager an important aspect of your job is use your technical aptitude to help your non technical peers clarify business ideas related to, possibly, technical problems. Once problems are clarified, it should be clear whether they are technical or not. At that point you then need to advise at the proper level of abstraction on cost, timelines, possible solution benefits and shortcomings.

Lets think about clarifying business ideas. Non technical people are familiar with issues in their business areas, but they may not be able to clearly describe the issue or identify root causes. Your job as a managerial level engineer may be to interpret a vague understanding that something is not as they want, into statement that can be evaluated as a engineering problem. You may in that interpretation process find that the problem at hand is not a technical problem or that there may be effective non technical means to solve it. Remember that people you are dealing with have developed very different skills to address issues in their businesses areas, and engineering style problem definition is likely not one of those skills. For example, a typical sales manager might deal with sales issues by getting a lot of people in a room, generating visibility, enthusiasm and consensus. He may see that as the way to solve engineering issues as well. Just as you may not have developed the skills to generate institutional momentum and enthusiasm, others may not have the developed the skills to approach problems with engineering perspective. Your value comes from doing that transformation for them and then communicating it to them in terms of their skill set.

Take an example, suppose a peer tells you that it is a problem that you do not "talk like a leader". What does he mean by a leader? I have heard hundreds of definitions of what a leader should be over the years. He is trying to express a mismatch between your managerial execution and his ideal, but I'm not sure if leader is the exact word he wants to express that mismatch. Which of my hundreds of "leader" definitions would most closely match his primary complaint about your execution style? Lets go a step backwards to "dont talk like an engineer". I suspect this statement is getting to the source of his primary complaint so lets investigate this statement.

I mentioned above that you need to advise at the proper level of abstraction and in terms of other peoples skill sets. If you are in a managerial meeting about a new product X and you start talking about Ruby on Rails vs Django or using C++ vs Rust, then you are talking at the wrong level of abstraction. The business does not care if X is Ruby on Rails or Django. They care about whether its a good technical idea. Should they put resources into X? How much will X cost? How long will X take to create? And most importantly how well X might or might not solve the well defined problem you clearly communicate? If you have ever talked technical details in a meeting, then you are talking like an engineer, and your talk is irrelevant to their concerns. Conversely, if you are ever in a meeting, and a peer manager suggests they really need a Y implemented to solve their problem Z, then your job is not to give them cost and timeline information on Y. Your job is to understand that your peer manager might, himself, be operating at the wrong level of abstraction. Y might the the solution to his problem, but maybe he would be better off with a different technical solution. Or maybe he needs to see the problem in a slightly different light.

I cant be sure, but I suspect that you dont have to change perspective and become a leader. Your perspective probably has a great deal of value to your company but you are just not presenting that perspective in a way your peers find maximally useful.

I do both and it's probably less effective (comparatively)

Reply on news.ycombinator.com