Last weekend I went to the Engineering Leadership Unconference in London. It was the first time I attended the "unconference" sort of event, which unlike as a usual conference, doesn't have a list of speakers or talks.
Instead, people meet and gather in front of a whiteboard and come up with topics to discuss. Each room is assigned a topic, and attendees are free to choose a room with the most interested discussion.
In each room there would be 5-10 people having a conversation for a given topic (let's say about growing developers). There's no leader and everyone is welcome to share an opinion. At the end of the time slot, they switch to another topic according to the whiteboard with the schedule.
It's a very cool format that IMO makes people feel more free to share their problems. In a small group of people you are a lot more comfortable to ask for advise related to a problem at work, unlike at a regular conference where you're in front of an audience and everything you represent is the public image of the organization you're associated with.
Thanks to carwow for hosting and organizing the unconference! Below in this post are some of my notes that could be interesting for others.
Promoting senior developers / career ladder
- Factors used to evaluate when a person is ready for promotion
- Values to evaluate at a company X: Tech excellence, Value delivery, Balance in quality, Always growing, Servant leadership, Further together, Taking responsibility
- Detailed matrix of criterias vs defining an image of a senior engineer and helping people to get to that image
- Turns out there's a guy running a consultancy about this!
Organic growth of engineering roles vs building a framework
- If you have a few engineers at the company and one of them really wants a promotion to senior, should you promote them for retain at the company?
- There’s no point in building a career ladder for a company of 10 engineers
- Reuse existing models instead of reinventing your own (http://www.progression.fyi/)
Environments without engineering managers
-
Developer anarchy: a company without managers, everyone works on whatever they want. Could be a good fit for a developer-oriented product (developers make tools for developers), but may not work for companies where the direction is defined from top level.
-
Tech Director (aka Google Fellow) model: exceptional engineers and engineers who’ve been delivering high-performance projects for years are promoted to be a Tech Director (TD). TD can work on whatever they want (it’s usually very complex problems that are hard to be solved by a product team), either individually of forming a small working group. They switch areas depending on where their help is needed. Compensation of TDs can be as high as for VPs.
Hiring principles
If we had one thing to look at when hiring, what criteria would we use?
Hire for delivery, fire for lack of enthusiasm - is what most of companies do
vs
Hire for enthusiasm, fire for lack of delivery (what was proposed)
- someone not having a track of delivery is not a reason not to hire them, if the team is excited to work with that person
- a lot of unexpected but turning to be amazing hires came from this category
