You're missing the most important kind of great engineer: the guy who's got adequate technical skills but fantastic executive functioning skills. A lot of bright engineers target the "fun" problem or will otherwise get distracted, leaving a lot of simpler tasks ignored. Every team needs the dev who opens up Jira, opens a sorted list of tickets, and just knocks them down one by one, all day every day. Without them, the product will crumble slowly around an increasingly amazing and elegant core.
IMO you need all types. A well-functioning team has people with different strengths that can get pathological when they go too far, and they cover for each other's strengths. The "just do it" high work ethic guys like that are great, but they can sometimes "just do it" in the wrong direction and don't stand back and ask if we should even do these things. "Mr. strategic" can sometimes stand back a bit too much and overthink things, etc.
Totally agreed. I feel like companies are always looking for engineers who can do both, but in reality, a good engineer CAN do both, but they tend to excel and thrive in one or the other.
You're 100% right but the mistake certain kinds of managers make is basically selecting (in performance review or in hiring, whatever) only for that kind of person.
You might get lucky and get the "creative genius engineer who is also an organizational freak who lives to squash JIRA tickets" ... but you also... might not.
The ultimate job of good management in a competently hired software development team is to uncork the potential of team members by finding the things stopping them from being productive, and getting rid of the blockage. Finger pointing about ticket tracking and demanding paperwork ... will not do that, at least not for everyone. For some class of team members the best thing management can do is find some way to accomodate their idiosyncracies.
This is assuming everyone is motivated. I assume most of us are only at work doing what we do at a "startup" type place because we like it and want to do good work. But not everyone agrees on how good work gets done and how to get there.
Too many people go into management for the status or control. In my experience, a good manager is more of a coach than a "boss".
Hey me too! I was actually surprised to learn that most developers aren't the type to just plow through a list of Jira tickets. Like, I thought that was the name of the job for engineers. Apparently not!
I don't think either type of engineer is better or worse than the other, but I do believe, as someone else mentioned, that both types are absolutely necessary to a team.
Eh, with good leadership who knows how to support different people with different motivations, you really don't. But good leaders are even harder to find and hire than good engineers.
The worst managers I’ve ever had didn’t use Jira, because they didn’t use much of anything at all, and everyone was confused about when and where their next task would come from. The answer was usually “they’ll message you at any time with a random request and demand a deadline at the same time”.
Jira helps turn terrible managers into mediocre ones, it at least forces them to write down what needs to be done and let’s me prove I’ve done the work back to them later when they inevitably forget.
The best managers I’ve ever had didn’t use Jira, because they didn’t use much of anything at all, and more senior engineers were trusted to manage work streams and run projects without needing to conform to a process demanded by someone not directly committing code.
Jira might turn terrible managers into mediocre ones, but it also turns good managers into mediocre ones too.
Depends - sometimes with simple Jira boards, sometimes with other tools like Smartsheets or Air Table or a simple spreadsheet, sometimes with post-its and a white board, sometimes with no system formal or otherwise. My point is less about Jira specifically and more about tool/process dogma (although I do think Jira is the tool of choice for most “we must used the Agile Toolkit Scaled Enterprise Framework Productivity System MegaProcess for all things!” types than others, mostly because of having been around forever and because of Atlassian pitching organizations to use Jira workflows for compliance as if it were uniquely capable of tracking when someone clicked a button in a UI).
One way is for senior engineers to give junior folks well-defined areas of responsibility, and then not worry about assigning and tracking small tasks within that. The more senior folks explain and motivate what we need and talk through what the interfaces around the area are and how it fits into the broader work of the team, then help as-needed.
Instead of trying to "track" work in terms of tasks, you keep up with the state of the system by understanding the state of each area. Which is pretty natural to do since you'd be helping with design discussions, code review and some pair programming and debugging.
This sounds really interesting, I bet it’s tuned to work really well for many engineering problems. I can imagine however that for certain company structures it would be a difficult fit.
Using JIRA isn't really the issue on its own. It's walking around with blinders thinking that tracking things in JIRA is how work gets done because it's invisible to you otherwise because you don't have your ear to the ground listening to your staff and finding out what's happening because you expect it all to be in the ticket tracking system.
JIRA is so dysfunctional in many places that people do a good chunk of intra-team planning in spreadsheets and docs instead, and use JIRA sparingly to make everyone faster.
I saw this effect live at my previous big tech after they moved to JIRA. JIRA got used way less than Phabricator because of all the friction it introduced and a lot more informal google docs + slack bot usage increased instead.
I remember to this day asking a report to plan more stuff in JIRA and seeing a beautiful task tree in Phabricator they did in the past. I asked why, and he shrugged and said it was just easier. That's when it really clicked for me. Linear can't come soon enough and burn JIRA to the ground.
I think the core error is marrying a communication tool for the people doing the work, to a reporting tool for people who aren’t doing the work.
Managers are all about that kind of automatic hyper-legibility (I’m skeptical about that being worth anything like the investment most companies put into it to begin with, but that’s another topic) but all it does is shove important communication into side-channels and make the ticket-tracker an extra chore, not a work aid.
Like if you’re often having to hound developers to update tickets (a thing in every single place I’ve worked) they clearly aren’t finding them a useful tool for themselves. You’ve wrecked that supposed use-case, it’s ruined.
It’s also the case that trying to serve both purposes, and in fact strongly favoring the PM + management use case, tends to make the UI for these things terrible for developers, contributing to their avoidance of them—the people who, ideally, would collectively be spending far more time in the tools than anyone else, are second-class citizens as far as those tools’ features and UX.
As a side note, as a developer I’ve never understood why other devs find updating tasks so hard. It’s super easy and makes you look good, and if I’d worked hard and not updated the ticket I can imagine that from my managers perspective it looks like I haven’t done much, that’s bad for me and I would get anxious and not want that. Should be simple, right?
I was the manager in this case, and I also hated JIRA with a passion. It's often the managers doing the alternative spreadsheets too and only using JIRA as necessary. I found you didn't need to "hound" developers with Phabricator and part of the hounding was me being hounded further up about it. Tools matter! Developers love automated organization!
It depends strongly on how it’s used. If you just use it for specific things it’s fine, trying to do everything in JIRA sounds like a terrible idea so why would anyone do that
There's a massive difference between "don't write anything down" and "don't use tickets". There are lots of (much better!) ways to write things down and to communicate than tickets.
More importantly, there are categorically better ways of understanding what we're working on than trying to break work down into bite-size linear "tasks".
