Totally - I think I may have a pathologically overactive brain that pursues lots of otherwise uninteresting or unimportant tangents with the curiosity of a child. Sometimes it can be hard for me to understand why some subtle phenomenon I happened to obsess over at some point isn't just interesting to normal healthy people.

You hit the nail on the head at post #1 when you said those questions shouldn't be asked by someone at the applicant's level, therefore nullifying any further engagement.

Right but I have no self control. I'm a troll's dream.

I'm not sure I agree with this, but its not really my focus. I'm thinking more of the team lead / director level equivalents.


Definitely agree that this is a big problem. To some degree if you want to go the management route you just have to be at a growing company, be some-what above average, and its just a matter of time before you're tapped to be a team lead and possibly even a director level positions.



Sure, but this is effectively true of almost every person/role at or above a certain level. I guess to be explicit I'm talking of a company with a meaningful engineering department and culture. Places where the software is a core part of the business and requires solving non-trivial problems. These places don't have shortages of real problems that need to be worked on and solved. And successfully solving these problems have noticeable impact on the company.

True. But that doesn't mean the right answer isn't to set up a good technical track. It's just that it has to be done well - which is the thing I'm thinking about.

I think you touched on the big concerns, in particularly you need people to be empowered to work on the important problems but also accountable for actually getting results.

I don't actually think it can be done purely without 'management' in the true sense of the word. So a technical leader (say a director level equivalent) doesn't need to manage people on hr issues, career development, motivation, etc. but does need to be able to have input into staffing, resource allocation, team/department goals, etc.

It's that balance that seems really hard to get right.



Again, I should have prefaced this with I'm talking about an organization with real and valuable tech problems. Maintaining a web site for a manufacturing company or mass producing simple apps isn't what I'm talking about.

So, if you mean "writing code" as literally "writing code", then I'm not talking about giving someone that just writes code a fancier title. I'm talking about giving people that solve real technical problems (sometimes writing code) like managing complexity, operating complex services, scaling efficiently, solving new and hard problems, etc. etc.

In the context I'm talking about I also dispute that management is a much more demanding and important job.

I don't know what you mean by "rejoin the two". Although, I guess for clarification I should add that in the context I'm talking about the management side is almost always technical as well up to (and often at) the executive level. So the management side is already a hybrid of technical and management skills.


I'm going to guess a company paying 500k cash to a director at an early-stage startup is going to have some issues with their board/investors. I'm also going to give me hot take that the vast majority of early stage startups shouldn't even have a director or VP role.

If we're restricting ourselves to startups with a meaningful business (raised non-trivial amounts of money or are successfully bootstrapping) I don't think its at all typical to say that a junior engineer can get a Director of Engineering title.

"Lead Engineer" type titles are given out pretty easily, but I don't think its common to give junior engineers director titles.

Not to that extent - managers who manage lots of people are almost always go deliver some results regardless of their individual impact so they are less pressured to deliver some significant change in order to justify their existence. Also, managers can be held accountable by their reports, whereas staff/principal engineer types can externalize the negative reaction that their action causes. I do agree that corporate politics favors action over inaction almost regardless of the efficacy of any action taken.

But even at such places, there rarely are pure technical problems of such high difficulty and to the extent there are, those are often undertaken by the teams that happened to have encountered them, not necessarily routed to the principal engineers or whatever.

Not having a technical track invites its own set of problems but yeah I'm not totally convinced either way.

Agreed.

The "junior engineer" term here is a relative term - L4 at Google would not be considered a junior engineer anywhere outside of the top few tech companies and would be better overall than senior engineers at the vast majority of tech companies. Another way to think about this is that the majority of senior engineers outside Google are both paid less than the average L4 and would have little to no chance of being hired as an L4 at Google.

In my mind, the people at the top of the technical ladders aren't just great programmers that are given hard problems to go off and solve. There are really valuable people that just want to be fed hard problems for them to solve by themselves - and there's often a place for that, but I don't think it involves promotions / title bumps. Although, it certainly might mean someone getting paid a lot more than their 'peers' at that level.

I think the technical leaders (let's call them T99s - the Gretzkys of programming) are people that are great programmers but much more importantly can see the big picture, work with other technical people, do reviews, lead designs, testing, implementation etc. They're people that can do things like identify where / how a system is going to scale and be proactive in addressing it. So let's say you've built a crazy kick-ass app and its usage is exploding. A T99 is a person that can identify the biggest technical risks and help figure out the appropriate solutions.

I think their 'scope' would match up roughly with their management equivalent. So a T22 might be a team lead equivalent and work at the team level. A T55 might be a director level equivalent and work across a group of teams with a relatively related purpose. And a T99 would be a VP level and work across a large portion of the company.

One more audit at T99 and I think you will go Clear.

Interesting discussion: lots of places try to sole the tech/management track differently, but despite lots of experimentation/various ways of drawing the line various places, there are few smaller organizations where it seems like it works well.

One challenge, I think, is at the beginning where I think the structure where the team lead is also the manager just works better than a complicated cross-functional thing.

Applies to "fellows" and star academics, but another (also small) category whih comes to mind for me are (successful) technical cofounders or early CTOs of tech-oriented startups.

cb,

Perhaps you should actually read what I write instead of making up strawmen, but you do you.

suzzer,

Toolish would probably be a more apropos for that rather than #humblebrag. But its w/e.

jj,

I think you basically summed it up in your last post. Some places call people who do this "product engineers" who are capable of ideation and don't need a ton of management to help understand how they can go about improving the product. So rather than continually working in parallel with a business unit that helps guide what they do day to day (effectively rendering them highly competent and well paid muppets) they instead have a degree of autonomy within their realm to experiment. Obviously these people aren't easy to find since finding someone who understands what the product is suppose to do and why while being able to write excellent code basically never occurs and these people then get channeled into just serving as intermediaries between people actually writing code and understanding the business use case. (Basically every middle manager handling engineers.)

Note: I've never seen product engineers at anything other than reasonable large startups. Also take this for what its worth, prob nothing.

It's tricky too, because there's clearly a line where I don't think it makes sense. If your engineering department is 20 people, you need some amount of minimal people management, but you probably don't really need a meaningful tech track because its easy to keep strong technical people engaged and accountable. Decisions are made at a level where they're very involved.

If your engineering department is 500 people then you need real people management. And if the people at the top of that hierarchy are also making all of the meaningful technical / design / cultural / etc. decisions than your strong technical people have to decide if they want to put up with management tasks just to get a seat at the table for the things they care about. This is obviously a ****ty situation for everyone involved.


Yeah, definitely. And so it seems obvious to me there's a line where it makes sense to make your hierarchy more complicated (along these lines), but where that line is depends on a lot of factors.

This isn't a unique problem though. A big challenge with growing a startup is figuring out when the current management structure (or lack thereof) is no longer working and what needs to change.

An amazing CTO (or even better CEO if its a tech startup) is even better than the T99 I mentioned. Because they know all of the things I mentioned, but also need strong management / business / product skills.


I think this is actually a different role than what I'm thinking of. But it very much flows from the specifics of the business.

Almost all of my work experience is in fast growing startups or companies solving very technical problems. In these cases the product is obviously important, but there's a whole class of problems and work that don't change the product in any direct customer facing way. For example, if you're going from X traffic to 10X traffic you might need to do a lot of work just to maintain the same user experience.

If a company doesn't have these types of problems (and lots probably don't), then yeah, I don't think the technical track that I'm talking about makes a lot of sense. Especially because one of the main goals of this is to recruit and retain really strong technical people that just aren't interested in management. The companies without these types of problems probably shouldn't be spending the time or money on these types of people because they're not that valuable to the business.

Some of that cb stuff is painfully absurd. A T4 engineer at Google could have 20 years of work experience or 0 days. The former would not be a junior engineer, the latter is literally the textbook definition. I have no idea what fantasy land he's ranting about at this point. We're into crazy town.

Beyond that the idea that a simple T4 designation at Google could qualify you for a Director of Engineering (without any idea of the responsibilities or scope or anything) is inane to a degree that I can't even bring myself to indulge in. I think that whole rant (that I initially made) was based on the fact that if you want someone competent, you need to pay them like they're competent. You aren't going to hire someone for 150k who is fielding alternate offers for 700k. It is really the whole crux of what I said before. But I guess if we can pretend that an Engineering Director at Gewgle and some kid who just graduated his PhD program and got an offer for his first job are equivalent for the task; sure whatever. Welcome to Planet Insanity.

jj,

I think mentorship/career guidance needs to be handle by direct superiors otherwise you're gonna end up with really ****ty employees. I don't think there is any reasonable way to have someone else talk about career advancement who has never been in that position.

I also think its a little silly to expect that individual programmers would have a meaningful say on a variety of things at a major company. Lets continue with the Google example. Do you think that a VP of Engineering there doesn't really understand what is going on? Or perhaps there are more pertinent issues than "This makes my life slightly easier day to day"?

Beyond that many of the strongest technical people (at companies that actually need people with specific expertise) will be focused on a specific niche product and not actually have issues with things like BYOD policy, whether we allow phone auth or keep a physical token, VPN policies, etc. It would be ridiculous for someone who has never done anything other than work at Intel and write processor code, then comes to a startup and starts to ramble about e-mail policy or device security. I'm sure this happens, but ultimately a lot of us need to understand that our opinions may very well be ****ty and beyond that, may not matter to anyone who actually has to make a decision. (Not that everyone isn't a special snowflake who has a meaningful opinion that should be listened to by someone else on any issue you deem worthy to ramble about.)

NB: I didn't think the product engineer thing was what you were talking about. I thought it was an interesting anecdote that is tangential.

This is probably true more often then not, but I don't think its as cut and dried as you say. And at the more senior levels I definitely don't think its that big of a deal. Success becomes getting results and not about specific implementations. It's easy for a manager to talk to their report about results without understanding all of the details of the job.

I have people that report to me where I can't speak to some of their specific decisions or specific actions they need to take to get ahead because they know a lot more than me in some areas. But I can definitely speak to results - things that are working and things that aren't. And if it gets to the point where I need to drill into the details then something very wrong has already happened.


I don't understand everything you're saying here. But my point is that its not reasonable to expect individual programmers to have a meaningful say on lots of things at a major company. But it seems really valuable to give technical people a way to progress up the ladder to the point where they can be involved in those matters without also having to take on a bunch of only semi-related management tasks.

When I'm talking about a technical track of promotion, I'm not talking about a way to empower individual programmers or anything like that. I'm talking about a way to empower top technical talent that don't want to manage people. Just because someone doesn't want to do regular check in meetings, set goals for a team, do reviews, deal with performance improvement plans, etc. doesn't mean they can't be much more useful than just as a great programmer.

I don't really get your examples here. They're not really what I'm talking about. I'm also going to disagree that many of the strongest technical people are focused on a specific niche product.

Again, I don't really know what you're talking about here. If you think these are examples of what I mean by "technical / design / cultural / etc. decisions", then that's not what I mean. I don't think any of the things you mentioned are particularly challenging or pressing problems faced by companies. That's not to say they're not important - but its really just a matter of making it someone (or some teams) job and letting them do something that makes sense. But they're pretty well defined problems with pretty well defined solutions.

jj,

Sorry if I wasn't clear. But for example, someone 5 years removed from FE development may have never used Angular, so he'd be unable to offer specific solutions about the actual problem in terms of specific implementation details. But he's gonna need whoever is his team lead or "Director of Engineering" to handle career mentorship. Not someone in product management or someone else who has never actually had the role he has currently. I think we may be talking past each other on that point.

wrt the rest. I think I get what you're saying now. I was confused before. I don't think that is really practical or necessary. Beyond that you find most people who're "very technical" but not doing management just have no social skills and no one is going to listen to them anyway. There is an inordinate amount of people who'd prefer a box of **** with a bow on top compared to anything useful. In this situation I don't even think it'd be remotely close.

While doing my usual googling-to-find-info-to-win-internet-arguments, I stumbled across this: https://medium.com/connect-the-dots/...o-a263f6724d63

The part about engineering leadership seemed relevant since you appeared to be talking about mid-size startups that were growing. (NB: I guess its good to point out that any titles I used were totally arbitrary and bear nothing in resemblance to actual titles someone may hold since who knows how organizations name every random person when they from from 8 engineers to 80. Who knows, the CTO may not even have 20% of the engineers reporting to him!)

Yeah, that's not what I'm talking about. Maybe its easier with an example. Here's a standard-ish hierarchy.

* Software Engineer
* Senior Software Engineer (May or may not have a team / management responsibilities)
* Architect (May or may not have a team / management responsibilities)
* Director of Engineering (Manages all team leads - so some SSE and some A)
* VP of Engineering (Manages Directors).

It's pretty much a single track and "Architect" is basically just a title bump for a Senior Software Engineer with little meaningful difference unless they then move on to be a director.

What I'm talking about is something more like:

Tech Track:
* Software Engineer
* Senior Software Engineer
* Architect
* Principal Engineer

Equivalent Management Track:
* Software Engineer
* Team Lead
* Director of Engineering
* VP of Engineering.

And it would be something like people being managed by the management level at or above them.

So in your example the engineer is going to be managed by either the team lead or the Director. If the engineer is interested in the management track, great. But if they're not interested, the manager still knows how to evaluate the engineer on the areas they need to improve on to make it to the next level. They have a technical background and as I mentioned before the promotion to Architect / Principal engineer is mostly about results and not about implementations.

In terms of day-to-day help with things like implementation details, that mentorship comes from their team, and whatever directors/vp/architects/principal engineers are knowledgeable and relevant to the technology and domain. This is basically how it works now anyway since the people that are most knowledgeable about various technologies don't always work on your team or manage you and a healthy work environment allows that sort of collaboration.

I 100% disagree with the idea that the non-management people have no social skills and no one will listen to them. Frankly, its sort of the stereotypical view that only comes from someone that has no technical background and has never worked on meaningful technical problems or with a large number of actual engineers. And while there are lots of great business that don't need any technical depth, those aren't the businesses that should ever consider anything like what I'm talking about.

But, I guess for the sake of completeness, I can explicitly say that communication with other team members and the ability to build consensus / present your ideas well is absolutely a prerequisite for any sort of higher level position on a technical track. If we're talking about the stereotypical no social skills but crazy good programmer, that person falls in the bucket of people that might get paid much better than their peers, but would not considered for a technical promotion.



I read this and my big take away is that I don't think his responsibilities are actually the right responsibilities for a generic "Director of Engineering". So, obvious caveat that growing startups don't need good generic job descriptions. They can (and should) make roles and fit roles to the people and problems they have.

But in general, most of this guys job sounds like it should be done by a product and/or project manager. There's no way he can do all of the things he's saying he does well for the long term. One big problem, imo, is that if he's doing all of those things he's going to be really far from the day-to-day work/problems that his teams are facing. And then it becomes really hard to be useful (and keep the respect) of the teams.

I think this sometimes works the other way - the management doesn't want to seem like they are the ones making certain types of decisions and as people managers, they care about how they are perceived so they "empower" the top technical staff to do the dirty work on their behalf. The problem to me is that unless you're dealing with very difficult technical problems on a day-to-day basis, those people have don't have much to do beyond these types of high-level stuff. And if you're not solving actual business problems every day, you're just as removed from the technical reality on the ground as the managers and perhaps even more so. I'm sure this depends but from my experience, most companies just don't have enough difficult technical problems - the biggest problems are almost entirely people and product-oriented.

Another thing is the talent distribution is very skewed in our industry. Because the top-tier tech companies pay much better than others, have much deeper career ladders and more challenging problems, people who are interested in purely technical careers disproportionately gravitate towards those. Middle managers and senior engineers are paid well enough at those places that most startups and non-techs have a hard time competing for top technical talents even with massively inflated titles. Startups tend to also innovate on the basis of product as opposed to engineering - where it outexecutes the incumbents, it's usually due to the more narrowly defined problem that's easier to solve.

The major impact of this talent discrepancy is that the bulk of the people that you'd want climbing up the technical ladder at your own company are already happily employed at a few large tech companies and they are not going anywhere. And even from home-grown talent perspective, the most exceptional junior people you can recruit tend to be skewed towards the more well-rounded ambitious types you'd want on management track, rather than technical gurus, simply because the top techs have such a gravitational pull on the latter types of people and pay them much more than they would be worth in an average tech company. While it's not impossible to combat this if you have the $$$ to run excellent recruiting operations, it may not be cost-effective in the long run. Another problem is that the best technical people you have, whether a co-founder or an early hire, are rarely going to want to hire someone that should, by merit, replace them as CTO or VP. Nor would they find it easy to identify such talents.

Again, I think I agree with you in principle but I can see why it may not work out as well for startups in 2017 as one would hope.

With that said, if you're a startup hoping to compete for top talent, you probably have to have a technical track even if it's just to say you do. Not having it says a lot of negative things about your engineering culture. So my reservation is more in regards to its efficacy and the extent to which you'd encourage your top people to stay on it.

no idea what this is referring to - I have deliberately avoided this derail like the plague

From another 2p2er. Other than the Android SDK - is there anything out there to make life easier for Android devs? Is phone gap still a thing?

Lots of stuff. Phonegap, Cortana, rubymotion, react native, etc.

You still have to learn about the platform and these things all fall down for anything other than simple apps that don't rely on phone features like gps or camera

I'm the 2p2er. It does need phone features.

What would your recommend? Briefly looking at what you listed I like them in this order from best to worst: rubymotion, react native, Phonegap, Cortana.

Don't do react native unless you want to become a Javascript and react expert. What languages do you know?

PHP is the only language I've used professionally for any extended period.

I did some stuff at work in Perl, Javascript and I guess Lingo (had to integrate with some Shockwave stuff).

A little fooling around on Delphi (Pascal). Took Basic in Jr. High and Fortran in college. Not much beyond hello world! in a few other things (C, C++, Python, Java).

I still feel like we don’t have a shared understanding of what these roles involve. I don’t imagine these people sitting in their ivory tower thinking up solutions to hard problems. They’re involved from start to finish. Sometimes that’s design / architecture and sometimes that coding / code reviews / doing ****. I actually think one of the big benefits of this role is that the people that can influence major decisions are much more in touch with the day to day reality because they don’t spend as much time doing management / recruiting / etc.


I disagree. Or at least it’s a combination of product and tech. But we don’t need to agree on this as long as we agree that we’re just talking about this for companies that DO have these technical challenges. Because again, if your company doesn’t have them it doesn’t make sense to pay / recruit / cater to top tech talent.

There’s lots (in percentage of total) of top talent available for startups because lots of people don’t want to work for a giant company. And the point isn’t to have a meaningless title. It’s to have actual roles with actual responsibilities and accountability. It’s an opportunity for a lot of people that doesn’t exist at large companies.

I’m also pretty unconvinced that the big companies have harder problems on average than many other companies. Sure, Google’s biggest tech problem is probably like super hard and interesting. But that’s not what everyone is working on.


I don’t think this is particularly true. But again, I don’t think it matters for this conversation. The thing I’m mostly interested in is places where people have experienced this and how well it worked or didn’t.

Disagree. I think you have a really skewed view of the effect of the large companies. Or a skewed view of the people that can do many of these roles. Like let’s say a ‘director’ level technical person is like top 3% of all software engineers. That’s still a really really big pool of people compared to what ‘a few large companies’ can employ.

This isn’t specific to a technical track. You could make the exact same argument about any hires. If anything the lack of a technical track makes this problem worse because the management track has a very clear number of slots based on people that need to be managed and new people automatically compete for those spots.

But, regardless, if the CTO or VP is actively not hiring people because they’re too good or because they can’t identify good - you have much bigger problems than org structures.


I do think it’s hard to get this right. That’s part of the reason I’m curious for how it’s gone right/wrong in places where people have seen it done.

This seems odd. Isn't RN really quite good? So same goes for the others, i.e. Don't use Android SDK unless you want to become a Java expert? Don't use Rubymotion unless you want to become a Ruby expert? I don't get it lol.