10 ms·

My experience as a Development Manager for the past ~year (YMMV): 1. I'm playing chess; senior management is playing checkers. No, not because I'm some sort of

My experience as a Development Manager for the past ~year (YMMV): 1. I'm playing chess; senior management is playing checkers. No, not because I'm some sort of genius and they are simpletons, but rather they talk about interchangeable "resource units" and I know these FTE's as "Tom" and "Amy", each with specific strenghts and weaker areas. Big strategic plans cannot differentiate but we front-line managers need to figure out how to position and leverage individuals. 2. Actually, genuinely, caring about your direct reports goes a very long way towards solving a lot of culture problems but... 3. Dev Managers need to put a lot of effort out into their teams to drive change and it is often (most of the time?) not returned. Your biggest enemy is not active sabotage, it's apathy at all levels of the organization. I started pushing for some specific cultural-ish changes about this time last year and, while I was given passive approval & support and lots of latitude to make change, it has been physically exhausting. If I was in an organization that didn't even give me this much freedom it would have been exhausting and pointless. 4. A Dev Manager can make localized changes when not all teams want or can reciprocate, but I'm not convinced yet that the requisite firewalls you need to erect aren't ultimately harmful in the long run. It is a very delicate balance. In the end my take-away is you need space and time to make any meaningful change, and even that is limited by the crushing inertia of the organization. For me personally it has been physically consuming and I have 6 month & 1 year goals, plus an overall 3-year plan that I'll either complete in the coming year or look for an new opportunity elsewhere.

DenisM 7y ago
Can you supply some examples of good goals? Thank.
- kfk 7y ago
  Not the parent but a good goal for me is a goal that will stand the test of time. If your change is fundamentally a good one and is part of a strong industry trend it will more likely succeed. I have been pushing a consolidation system for finance (2,000+ finance professionals where I work) over the past 3 years, only lately it's picking up steam with the leadership. If I had been pushing a change that was not so strongly trended (automation and all) I would have failed because something else would have come up as "best practice" in the industry. This does not mean you just go with the industry and become a "benchmark" monkey, hype is still a problem. Take AI, Big Data, etc., those are not so good trends to latch on today because they seem to be too hyped. But it means you stay real with yourself, your company and, most disregarded, your industry.
deleted 7y ago
[deleted]
skittleson 7y ago
Those insights are right on. I respect those dev managers beyond measure... they have to say no often and deal with the org red tape.
klenwell 7y ago
Well stated. Bookmarked. One additional bullet point I would add: Hiring. If an isolated HR unit controls hiring and freezes the hiring managers and team out of the process, or effectively alienates them, you're wasting a huge amount of energy. This is part of the methodology I try to weave into my organizations: - A thoughtful and literate job posting, purged of gratuitous jargon, will accurately describe the job and foreshadow the company culture. - Candidates will be evaluated using a simple quantitative assessment of core competencies (see Ch. 21 of Kahneman’s Thinking Fast and Slow). - Final decision will be a collective decision of the hiring team. - After hiring cycle is complete, hiring team will hold a retrospective. - We will acknowledge mistakes and work to correct them quickly and humanely. https://wiki.klenwell.com/view/Hiring https://wiki.klenwell.com/view/Hiring
- avip 7y ago
  >Candidates will be evaluated using a simple quantitative assessment of core competencies. I've tried implementing that with a coding take-home task, with "mixed results". On-paper great candidates often refused. On-paper good candidates made mistakes because they completed it very quickly, while mediocre candidates invested x10 the time and produced "better objective result". Comparing code turned out to be much less straightforward or objective than I've anticipated: X handed great consistent well-commented code, but didn't null check inputs, Y covered all cases but left internal class implementation details public, and so on and so forth.
  - WalterSear 7y ago
    So, what is more effective than a talk home task? I posit it's still the least bad way to evaluate a candidate. If a 'mediocre' candidate is able to complete the task well, they have still completed the task well. And, IME, 'great' candidates, even with a storied resumes, can simply be good at self-advancement and job application as much as actual competent at their job.
  - lostcolony 7y ago
    So...how did you actually do in filling the role? I don't care how someone looks on paper. Nor should you. Your process should optimize for people who are good at the job. You can look at all the negatives and try and guess "maybe that was a false negative!"...but who cares? What's your rate of true/false positives? That's the only data point you have; optimize for that.
hinkley 7y ago
From the other side (lead dev) I feel the apathy part pretty acutely. I go so far as to say I think Hanlon needs a new razor. Never attribute to stupidity that which can be adequately explained by apathy.
darkerside 7y ago
A few thoughts. If you want a better analogy that doesn't belittle senior leadership, try Go instead of Checkers. One of the keys to successful management and leadership is understanding sustainability. Incremental changes over a period of time beat a huge lift followed by burnout and stasis.
- closeparen 7y ago
  A senior leader wouldn’t be caught dead holding the same position for more than 18 months. The whole game is to make a huge lift, collect the monetary and prestige rewards, and move on to the next thing before burnout becomes apparent. Sustainability is the domain of entrenched/ossified/bureaucratic middle managers, moderating or outright sabotaging whatever BS senior leadership is excited about this month.
- proc0 7y ago
  I actually think current "leadership" is on its way to being extinct. It will be replaced by algorithms and best practices, along with better tools. If you're not contributing to code, there will be very little room for them in the software company of the future. The concepts that non-technical leaders have to learn are trivial compared to the advanced techniques of software development.
  - james_s_tayler 7y ago
    You're joking right?
    - proc0 7y ago
      No, but I did leave out some important clarifications. It's not that leaders will go away, but that I think leaders will also be required to contribute to some code. Also this isn't in the near future either, but just like many roles (i.e. QA), leadership will slowly become absorbed by developers who will have multiple specializations along with knowing how to code.
      - 7y ago

DenisM 7y ago

Can you supply some examples of good goals? Thank.

kfk 7y ago
Not the parent but a good goal for me is a goal that will stand the test of time. If your change is fundamentally a good one and is part of a strong industry trend it will more likely succeed. I have been pushing a consolidation system for finance (2,000+ finance professionals where I work) over the past 3 years, only lately it's picking up steam with the leadership. If I had been pushing a change that was not so strongly trended (automation and all) I would have failed because something else would have come up as "best practice" in the industry. This does not mean you just go with the industry and become a "benchmark" monkey, hype is still a problem. Take AI, Big Data, etc., those are not so good trends to latch on today because they seem to be too hyped. But it means you stay real with yourself, your company and, most disregarded, your industry.

deleted 7y ago

[deleted]

skittleson 7y ago

Those insights are right on. I respect those dev managers beyond measure... they have to say no often and deal with the org red tape.

klenwell 7y ago

Well stated. Bookmarked. One additional bullet point I would add: Hiring. If an isolated HR unit controls hiring and freezes the hiring managers and team out of the process, or effectively alienates them, you're wasting a huge amount of energy. This is part of the methodology I try to weave into my organizations: - A thoughtful and literate job posting, purged of gratuitous jargon, will accurately describe the job and foreshadow the company culture. - Candidates will be evaluated using a simple quantitative assessment of core competencies (see Ch. 21 of Kahneman’s Thinking Fast and Slow). - Final decision will be a collective decision of the hiring team. - After hiring cycle is complete, hiring team will hold a retrospective. - We will acknowledge mistakes and work to correct them quickly and humanely. https://wiki.klenwell.com/view/Hiring https://wiki.klenwell.com/view/Hiring

avip 7y ago
>Candidates will be evaluated using a simple quantitative assessment of core competencies. I've tried implementing that with a coding take-home task, with "mixed results". On-paper great candidates often refused. On-paper good candidates made mistakes because they completed it very quickly, while mediocre candidates invested x10 the time and produced "better objective result". Comparing code turned out to be much less straightforward or objective than I've anticipated: X handed great consistent well-commented code, but didn't null check inputs, Y covered all cases but left internal class implementation details public, and so on and so forth.
- WalterSear 7y ago
  So, what is more effective than a talk home task? I posit it's still the least bad way to evaluate a candidate. If a 'mediocre' candidate is able to complete the task well, they have still completed the task well. And, IME, 'great' candidates, even with a storied resumes, can simply be good at self-advancement and job application as much as actual competent at their job.
- lostcolony 7y ago
  So...how did you actually do in filling the role? I don't care how someone looks on paper. Nor should you. Your process should optimize for people who are good at the job. You can look at all the negatives and try and guess "maybe that was a false negative!"...but who cares? What's your rate of true/false positives? That's the only data point you have; optimize for that.

hinkley 7y ago

From the other side (lead dev) I feel the apathy part pretty acutely. I go so far as to say I think Hanlon needs a new razor. Never attribute to stupidity that which can be adequately explained by apathy.

darkerside 7y ago

A few thoughts. If you want a better analogy that doesn't belittle senior leadership, try Go instead of Checkers. One of the keys to successful management and leadership is understanding sustainability. Incremental changes over a period of time beat a huge lift followed by burnout and stasis.

closeparen 7y ago
A senior leader wouldn’t be caught dead holding the same position for more than 18 months. The whole game is to make a huge lift, collect the monetary and prestige rewards, and move on to the next thing before burnout becomes apparent. Sustainability is the domain of entrenched/ossified/bureaucratic middle managers, moderating or outright sabotaging whatever BS senior leadership is excited about this month.
proc0 7y ago
I actually think current "leadership" is on its way to being extinct. It will be replaced by algorithms and best practices, along with better tools. If you're not contributing to code, there will be very little room for them in the software company of the future. The concepts that non-technical leaders have to learn are trivial compared to the advanced techniques of software development.
- james_s_tayler 7y ago
  You're joking right?
  - proc0 7y ago
    No, but I did leave out some important clarifications. It's not that leaders will go away, but that I think leaders will also be required to contribute to some code. Also this isn't in the near future either, but just like many roles (i.e. QA), leadership will slowly become absorbed by developers who will have multiple specializations along with knowing how to code.
    - 7y ago