Software Engineering Leadership

Add a comment

Software Engineer leadership is where you lead/manage a number of software engineers, directly or via another manager(s). Your title could be Engineering lead, Software Engineer manager, R&D Manager, Director of Engineering or VP of Engineering or CTO.

The focus of this article is for companies that are less than 15 years old and more a SASS company. For example you don’t see an explicit CIO role in most startups, you tend to see them in much older organizations especially public ones.

Your work will be split between four main areas: Human, Process, Product and Technology. The higher you go the more your system design/architecture skills will matter and your coding less (unless you are in a small company).  You will be wrangling with managing people, process, product whilst evolving the technical vision to fit all of your constraints. Hopefully you will be delegating and keeping a lot of things out of the way of your engineers, so that your engineers can code.

In the end your short/medium term success will be determined by whether you can deliver the needs of product, keep your engineer team motivated and fully explain what is going on e.g. translating complex technical things into a language everyone can understand. Your long term success will be based in whether you made the right choice/balance between building out features vs platform and whether you upgraded your team in the right way – all why you helped the company stay in business.

A layer of good, well-trained, and experienced managers makes a massive impact on allowing engineers to deliver on features and a solid platform, whilst growing those engineers to their full potential. A courageous leader will be copied, by others.

This post is the first, of at least five more posts which will cover in depth Human, Product, Process and Technology. For these topics I have provided a summary within this post. If Leadership specifically is of interest you can see some of my thoughts in the 19 Leadership Posts.

In this post I will cover:

  1. Who leads who?
  2. Founding Culture
  3. Levels of Engineering Leadership
  4. Areas of responsibility:
    1. Human
    2. Process
    3. Product
    4. Technology
  5. Why am I a Software Engineer Leader?
  6. Other Perspectives on Software Leadership

In each section I have included Code-smells, patterns and anti-patterns to look for, I will keep adding throughout my career. Any engineer will know these are things to look for but do not always predicate a problem… Every organization will have anti-patterns and code-smells, identifying them helps you choose if that is the set of problems you want to work with or not.

Who leads who?

One of the first questions I ask in the interview, “Is software engineering a servant to Product, or vice versa or is it a true partnership?” This allows you to unpack who is leading who and understand the dynamics of this role. Really understanding the political make up will often tell you the type of job you will do as a software engineer leader within a organization.

Sometimes you will find the culture is dominated by Sales especially in business to business (Hint – This can lead to a big divide  between release dates and expected date by clients).

Patterns to look for:

  1. A partnership between Product, Design and Engineering
  2. Tech Debt is understood including how it is created
  3. Platform engineering is understood
  4. Data is valued and its engineering is invested in

Anti-patterns and Codesmells to look for:

Ask to understand why if these are the case, context matters and you will have a better understanding of the people and their culture:

  • Engineering tells Product what to do -> The end product may miss the human factor, may not truly understand the customer, a lot of other departments will be frustrated – do not undervalue the importance of good Product People.
  • Product tells Engineering how to do -> This often leads to a feature factory and under investment in your platform, leading to much bigger rebuilds to scale well. Retainment will be tough amongst engineering.
  • Sales sells things that we have not built, designed or have the capacity to build. If It is common for Sales to oversell their products, you are creating an awful environment for both your Customer and Engineering people.
  • For Startups -> Is there a lot of “Playing Favorites” amongst the first tribe of people -> Leads to all new people feeling undervalued and retainment is tough.
  • There are no leaders with courage e.g. decisions are put off -> leave get another job or teach them how
  • You have no data specialists e.g. Data Engineering or Data Scientists -> without reliable data you do not know what is truly going on and you will not provide good analytics/reporting or have a hope to use Machine learning
  • You have no single source of truth for your data -> if you cannot trust reality and you have to guess, I hope you have some very lucky people -> Fix this!
  • A lack of trust in the engineers -> “hand on leadership” -> micromanages, still codes, does not pay enough attention to their people and their potential
  • Design i.e. Product Design, UX, UI has no voice
  • The Engineering Head of Department reports in to a COO and not the CEO

Founding Culture

I am going to assume that you have established product/market fit. As before that point the relationships and problems are very different. (Thanks Glen for the reminder) – lots of experiments by Product to figure out the business.

The next area I focus on is how respected/trusted technology is within the organization.

One of the strongest influences is whether there was a technologist within the founding team and whether they are still with the business. If not, you have a lot more work to do. If it is a Startup, also knowing if one or all of the founding members has made a full transition to the C-Suite or not (they may have the title), this is easy to tell by the decisions they get involved in e.g. they are still coding, the button should be blue, you should hire an engineer not a DBA…

Patterns to look for:

  • The Co-founders have or had Executive coaches to help them grow through the different stages of the business
  • The Co-founders have not become bottle necks for decision making
  • There is a list of things we are not going to do
  • You get a lot of questions from co-founders as they figure you out but they come with curosity nor judgement.
  • The Co-founders can be explicit about what they want
  • The Co-founders have a good level of management experience in multiple organizations

Anti-patterns and CodeSmells to look for:

  • The Founder/CEO decides what roles you hire for e.g. Full Stack Engineer vs DBA. Expect challenge, this is good, but if you have an agreed-upon budget and you are within it, then the actual Engineering Leadership should be able to choose how to solve their problems
  • Co-founders are prone to”digging in” or micro management. This is not be confused with collaboration or how you the delivery from Engineering is observable
  • “Over” involvement from Founders/CEO in Product Design, everyone may have opinions, but you should trust the designers/POs/PMs or hire better ones and let them do their job
  • Product is not talking to customers or sharing designs
  • You are waiting until everything is “perfect” before release e.g. Waterfall rather than Agile
  • There is a lot of opinion and there is no A/B testing with customers
  • Sales, Integrations or/and Product complain that engineering can never deliver on-time i.e. blame culture or worse it’s true.
  • Choices are always made from data, i.e. the past -> may show lack of risk/innovation
  • Too much bias to action – most founders need this to form a startup, but need to back off as the company grows and trust others
  • The CTO or the Head of Engineering does not attend the Board a couple times a year. Some founders find it hard to let other Executive into the Board – be curious here not judgmental.
Steve Jobs

Levels of Engineering Leadership

Below are some of the common leadership positions within Software Engineering, not every organization will have them all and what you do in each role will vary massively on the size of the organization and how many engineers you have.

Size of the company will impact each role. For Example a CTO of total team under 10 people, tends to more of an Engineering Manager or a Tech Lead

Technical(Tech) Lead Role

Sometimes the leader will be the “technical lead” and sometimes not. If you want self organized teams the Tech lead should NOT be a position but instead an opportunity for all team members and should be based on a project or an epic. A great tech lead is a good influencer, educator and ensures that others in the team get to be heard and their ideas explored. A Bad Tech lead tells the software engineers all the time how they will Architect/design each feature e.g. micromanagement.

A great tech lead will share, and keep sharing domain expertise around the team. This will help engineers grow and it will also not be so painful when an engineer leaves with ALL the domain knowledge for ALL the areas. Leading an area/domain will also allow a person to start thinking bigger e.g. have the opportunity to consider the strategic implications for their domain rather than just tactical feature additions.

Personally i prefer this not to be a Job title, but a responsibility that is taken on for a specific project/epic even feature if complex enough. Why? because I would everyone in the squad/team to get the opportunity to be a Tech Lead and learn/fail at it.

Engineering Lead/Team Lead/Squad Lead

This role is a split between management and Individual Contributor i.e. still contributing code. Usually manages a couple of people (1-3). Beyond leading three humans (depending on the humans) and they will likely be not contributing so much.

This position might the first rung on the ladder for managing other humans.

This position may exist in Command & Control/hierarchal/authoritarian structures and not in organizations that are flat or have self organizing teams. Their work may be split between the following:

Technical (approx 60%)

  • Coding/code reviews (40% to 60%)
  • System Design/Architecture (10% to 30%)

People (approx 20%) 

  • Coaching team members (5% to 20%) e.g. one to one meetings and in the moment coaching, higher for more junior team
  • Team Building (0% to 10%) e.g. creating bonds, building resilience
  • On-Boarding (0% to 10%)
  • Administration (10% to 15%) e.g. performance reviews, recruitment, other HR/Finance needs

Processes (approx 20%)

  • Team Processes e.g. Agile (10% to 30%) e.g. standup, grooming, technical grooming, planning, Retros, sprint review
  • DevOps/Operations/Fires (0% to 50%)
  • Managing Up (0% to 10%)
  • Inter team alignment (0% to 10%) e.g. Platform, Security, API, Mobile etc

Product (approx 0%)

  • Product conversations (0% to 20%)
  • Product Design (0% to 10%)

Realistically this is the last level that you will spend a lot of time coding unless you are in an early stage startup. If you are lucky and you have a good manager above you this may be still be possible. If you are in a specialized team and the only one of its type e.g. Mobile, Security or Data – its is likely you will have a lot more work in terms of educating, championing for that specialization e.g. presentations, coaching engineers, etc.

Whilst some organizations call this position Engineer Manager, when they says “Hands on Engineering manager” I would say they are looking for the Eng Lead role, and they optimistically hope you can manage a bunch of engineers and code. Shopify has this role, I would also say Facebook Eng Manager role is more technical than people orientated and thus fits here.

Engineering Manager

Likely has between 4 and 12 engineers who report to them in one team. Science shows that the sweet spot is between 3 to 9 engineers. In some cases each team will have a Tech Lead or a Team Lead who reports into you the Manager. Younger organizations may give you multiple teams, which will likely stop your time coding. Team health will be one of your priorities at this level, along with Team Delivery and Team quality.

An important foundation of engineering management is to be removing a lot of people/process/bureaucracy out of the way of engineers so that they can spend more time with code. If your head is down coding there are a lot of things you are likely missing.

Building a career path for each of your engineers is very important to help them grow. This will be a few minutes here there and everywhere. “Who should go on this new team” conversations, to sharing the work or they way they work with colleagues and others. You need to be an advocate/champion for each of your engineers and those moments will sometime be opportunistic and others carefully planned. The getting the actual ready for that moment is covered under the coaching and creating a career plan. Ensuring each of your engineers has purpose, autonomy and growing mastery is the set of keys to their and your success.

Your time will be split all over the place and you must be good at context switching to survive this role.

Technical (approx 20%)

  • Coding/code reviews (0% to 60%)
  • System Design/Architecture (0% to 20%)
  • Technology Strategy (0% to 20%)

People (approx 20%)

  • Coaching team members (10% to 30%)
  • Building a career path (0% to 30%)
  • Team Building (0% to 20%)
  • On-Boarding (0% to 20%)
  • Recruitment (0% to 50%)
  • Administration (10% to 30%)

Product (approx 10%)

  • Product Delivery & Development (10% to 30%)
  • Product Design (0% to 10%)

Processes (approx 50%)

  • Team Processes e.g. Agile (10% to 30%)
  • Documentation (10% to 20%)
  • DevOps/Operations/Fires (0% to 50%)
  • Building processes/policies/systems (10% to 30%)
  • Managing Up/Reporting Up or Internal Presentations (0% to 20%)
  • Engineering Leadership Alignment (10% to 30%)
  • Inter team alignment (10% to 20%) e.g. Platform, Security, API, Mobile etc

Exception -> You lead a research team (The R in the R&D) or a Mobile team in a web company. You will have to do a lot of championing, advocating and explaining your tech to others.

Areas to focus on

  • Team Delivery – Delivery of commitments e.g. features/stories, etc
  • Team Health – wellbeing of each of your Humans
  • Team Quality – How good is the work of your team? e.g. Observation, Testing, Incidents
  • Team API – How easy is your team to work with? From the perspective of other teams.
  • Reduce unnecessary process
  • Ensure shared understanding with team and product
  • An actual Career – Career paths for each of your engineers

Director of Engineering

Often you are managing managers. You will likely be involved in some level of architecture of system design, but only to understand when big choices are being made. You will be responsible for creating/building processes/policies/systems e.g. interview process or career ladder for all engineer types for the whole department. You are likely to have some budget to control.  You may also manage senior technical people who are in charge of domains of engineering e.g. Front End, Data, Test, Platform etc.

At this level you may also start been concerned with what does your platform look like in 2 to 3 years in the future. For example you may want to move beyond a monolith to services based architecture. Thus you will have to work with product to take the big picture perspective and not just worry about how many features can you ram into the monolith.

Technical (approx 10%)

  • Coding (0% to 20%)
  • System Design/Architecture (0% to 20%)
  • Technology Strategy (10% to 30%)

People (approx 25%)

  • Coaching team members and managers (10% to 30%)
  • Building a career path (0% to 30%)
  • Team Building (0% to 10%)
  • Recruitment (20% to 50%)
  • On-Boarding (0% to 20%)
  • Administration (20% to 50%)

Processes (approx 45%)

  • DevOps/Operations/Fires (10% to 50%)
  • Building processes/policies/systems (10% to 40%)
  • Documentation (0% to 20%)
  • Managing Up /Reporting Up or Internal Presentations (10% to 40%)
  • Engineering Leadership Alignment(10% to 30%)
  • Inter team alignment (0% to 20%) e.g. Platform, Security, API, Mobile etc
  • Vendors (0% to 20%)

Product (approx 20%)

  • Product Roadmap Priorities (0% to 20%)
  • Platform/Core/API Infrastructure champion (10% to 20%)
  • Product Delivery & Development (10% to 40%)
  • External Representation (0% to 20%) e.g. conferences, talks, etc

Exception -> If you have people above you within Engineering (e.g. Product or Founder background) who do not have engineering experience your time explaining what you are doing and why will increase, a lot.

Areas to focus on

  • Delivery of commitments e.g. features/stories, etc
  • Managers Health/Growth
  • Reduce unnecessary process
  • Ensure shared understanding with your managers and product
  • Career paths for each of your managers

Vice-President of Engineering

The VP Engineering or VP role can really differ depending on the size of the Engineering Department. In companies with over 30 Engineers you may be the Head of Department and the role is often all about recruiting, management, internal communication and delivery — getting the product out the door, while ensuring the team is delivering the agreed roadmap. You are often managing managers and directors. A wide perspective on how your technology works and Leadership development will be core in this role. Your focus will often be split between internal and external e.g. staff vs vendors. And your work day will be split between high-level direction/strategy, choosing between technologies, long-term technical and product strategy, working with legal department/people on technical matters, signing of partnerships with vendors, and evolving the engineering culture you want/need.

Post 2020 Many VP Engineering are the equivalent of Directors and have a couple teams and will not be members of the companies Executive

Technical (approx 10%)

  • Coding (0% to 10%)
  • System Design/Architecture (0% to 30%)
  • Technology Strategy (10% to 30%)
  • Where is the world going in technology (competition/partners/industry) (10% to 20%)

People (approx 30%)

  • Coaching team members and managers (10% to 30%)
  • Team Building (0% to 10%)
  • Recruitment (20% to 60%)
  • On-Boarding (0% to 20%)
  • Administration (10% to 50%)
  • Where is the world going in people (competition/partners/industry) (10% to 20%)

Processes (approx 40%)

  • DevOps/Operations/Fires (10% to 50%)
  • Reviewing processes/policies/systems (10% to 40%)
  • Documentation (0% to 20%)
  • Managing Up /Reporting Up or Presentations (10% to 50%)
  • Engineering Leadership Alignment(10% to 30%)
  • Vendors (0% to 20%)
  • Business Strategy (10% to 30%)

Product (approx 20%)

  • Product Roadmap Priorities (0% to 20%)
  • Platform/Core/API Infrastructure champion (10% to 20%)
  • Product Strategy (10% to 30%)
  • External Representation (0% to 30%) e.g. conferences, talks, etc

You take the base % of each category you may notice its above 100%, yes you will find you miss the days of 9 to 5, to keep up you will need extra hours to have the information you need or have great people who can support you.

Areas to focus on

  • Budget
  • People Planning
  • Culture
  • Managing Up
  • Keeping the Executive informed
  • Team Health
  • Reduce unnecessary process
  • Ensure shared understanding with team and product
  • Career paths for each of your Managers

Time to think strategically

This role can also be dramatically different if there is no CTO. Note the senior leadership capacity (number of people) for each department, it will often show the balance of influence of each department e.g. if there is a VP of Eng, but CMO + VP Marketing and directors. Marketing will have more edge, as the CMO has more time to think through things versus the VP of Eng who may be “running the department” and have less strategic thinking time.

VP Engineering Patterns and AntiPatterns

The success will depend as much on the CTO and as the team. A great partnership with the CTO is essential. These could impact at every level below:

“Its still my baby” Homegrown CTO or Technical Founder – who can not let go – they are still coding or “advising” on features and code that they built. This can help in organizations that the person above does not “know” technology or there are no board members who come from a Technology background. They may only employ “hands-on” people as they have not learnt how to grow others, and/or trust other engineers.

External only focused CTO – They spend a lot of time winning awards, helping the community at conferences. They do not focus on the C-Suite or understand what is going on in their department.

Resources for VP Software Engineering

Chief Technology Officer (CTO)

Assuming the CTO has a VP of Engineering a lot of their time will be spent with you primary team e.g. C Suite or as the external face to the company. They will be a professional in translating and communicating technical issues in a language everyone can understand (mostly business/finance language). They will be helping the organization define the balance between new feature development vs. Tech Debt. They may also do a level of Product depending who owns Product at the C-Suite level. They will also be driving business strategy and revenue through identifying and implementing new technologies. They know where is the world going in technology (competition/partners/industry. They will be often looking after the Board in relation to Technology, they may be forming strategic technical partnerships. Or research for M&A related to the tech. Or they maybe the chief architect. The interplay between this role and a VP of Engineering will often working in partnership.

Types of CTOs

There are many different types of CTOs, this list is not exhaustive:

Head of Technology CTO – CTO & VPE partnership

One dimension that differs is responsibility for Technology choices and being the Head of Department. This can be the classic CTO (Head of Technology and maybe Architecture and the VPE is the Head of the Department i.e. People, Process and Delivery). In this setup the CTO works at the high level of technology and maybe more of architecture and educator and less so on coding to Production but coding for Evaluation and Education

Leading Engineer CTO
In some companies the CTO role is actually like a Principal Engineer and works only on technology and not with the C-Suite so much. This often a pattern where the co founding CTO, would rather focus on the technology and less so on the business and its people

Leading Sales Engineer CTO

Especially common in B2B and Hardware, where they are on a lot of Sales calls and talks to Customers on a regular bias

CTO – Leader of Technology and Head of Department

More common in modern day “Web/Mobile” companies formed post .com boom in the 90s.

Patterns

Transparency – You can talk to the previous CTO without any hesitance from the current Executive

Board – You are expected to attend the board on a regular basis (maybe annually) and there is at least one board member who was a technologist

Anti-Pattern

Lack of support – If the CTO does not have a VP of Engineering (or a Chief of Staff) and there are multiple Execs from other departments on the Executive, it is likely if you have a department of over 50 to 70 you will be very likely very internally focused and not have the slack to much external i.e. you will be over worked.

Job Description – Reads like it was not written by a Technologist, maybe the HR/People team wrote it?

Resources for CTO

Chief Information Officer (CIO)

Sometimes this role will be part of the CTOs role. CIOs work on setting strategy and direction to manage the company’s internal infrastructure and technical operations. That can include employee software applications/tools, internal communication (e.g. wiki, IM), technical infrastructure (e.g. wifi), process control, access control, employee network, cost management, integration of technologies across departments.

Splitting Tech between CTO and CIO can create some very “interesting” dynamics, often creating many extra problems at the ground level within DevOps, perceived (sometimes real) boundaries e.g. who is responsible for this (“Throwing over the Wall”)or within movement of engineers from one role to another.

Other C-suite tech focus roles

CSO or CSIO

Security is incredibly important and depending on the Risk for the Company this role may exist. Often with a focus on Corporate Secuirty

CAO

Chief Architecture Officer tends to focus on the Platform, set Architecture patterns on systems that are highly distributed and complex

CDO

Chief Data Officer tend to focus on a Data running through the companies system both internally and externally

Engineering Leadership

Some companies think they can get by with no real management. They rely on Tech Leads (who are given no effective training or support), ignore engineering management and the next title is a Director, VP or CTO. They often do not train/coach/mentor their engineers to their potential. Thus there will be little coaching on communication/people skills if they are weak, and engineers often ask about their next career steps, some will find it easier to get “their” promotion by leaving. The lack of growth in communication/people skills has massive impact on the culture of the organization of engineering. In addition, learning to coach/mentor/teach is a set of skills that can take a while to learn fully. Sometimes this will be dismissed as “Soft Skills” – Presentations, Empathy, Feedback, Influence are all skills that will determine your success as a business and thus in my book are “Hard Skills” and all can be taught/coached. For those that feel they can avoid these skills by taking the Technical pathway, have yet to try to convince engineers, in multiple teams, to change what they are doing..

“Hands-on”

or are you technical is a term that is thrown around without understanding. It can show that the organisation needs technical leadership, it can also show there is no trust in the engineers, which also show no “growing”/coaching/mentoring exists or many other things. This is a debate that exists with technology that will never go aways because it is the attempt to understand the balance between your technology skills vs people skills. It is also overlapped with the bigger conversation between specialist and generalist and what they both mean. I also wonder if it leads to Ageism that we see in the tech sector.

Anti-Patterns and CodeSmells in management/leaders of Engineers

  1. Someone who is in an engineering leadership position without ever been an engineer
  2. There is a blame or fear culture
  3. The engineer leader has never received any training or quality coaching
  4. Engineers are only valued based on the code they produce
  5. All engineers are full-stack engineers
  6. No Career Ladder for Software Leadership
  7. No internal promotions to senior leadership roles
  8. Too many internal promotions
  9. Your CTO or VP (not a tech co-founder) is writing code
  10. The CTO and VP Engineering are not aligned
  11. There is no CTO or no VP Engineering
  12. Anyone making engineering decisions when they were never an engineer
  13. No Engineer Managers for companies with over 30 Engineers

Areas of responsibility

There are four areas of responsibility that exist throughout all software engineer leadership. How much of each you will have to manage, will vary by company, culture and role. I will give a summary below and I am writing a separate blog or two on each area. The four areas to manage are P4T:

  • Human
  • Process
  • Product
  • Technology

IMG_0253

1. Human

Help your engineers become the best version of themselves, grow great teams, have a place people want to work, be the leader people want to follow

How good are you with humans and interacting with them? Do they leave conversations with you drained or empowered or confused?  How do you help them evolve to be the best version of themselves? Some people dismiss this as “soft” skills, frankly if you are an effective leader this will be the “hardest” skill you have. You could help an engineer go from good work to excellent work. People leave poor leaders

  • Can you lead or influence other people, without position/title?
  • How good are you at conflict/disagreements?
  • Can you share your opinion and people listen?
  • Can you educate people through presenting or mentoring or coaching?
  • How often do you have one to one meetings?
  • How do ensure that you cover coaching, operational issues and career pathway – in your one to ones?
  • How do you manage your emotions? How vulnerable can you be?
  • How do you intentionally or otherwise affect other people’s emotions?
  • Do you understand how your decisions will affect your team’s emotions?
  • How good are your change management skills? Are they surprised?
  • How do you structure the department and teams?
  • How do you grow each engineer?
  • How do you grow each team?
  • How do you grow the Department?
  • How do you help your stakeholders grow? and understand your team(s)?

Anti-Patterns to look for:

  1. There are no one to ones
  2. Your manager is never available
  3. The engineers are not diverse in any way
  4. Poor Reputation amongst the engineering community
  5. A weak or impersonal interview process
  6. Managers have more than 10 staff reporting directly to them
  7. There is no Technical career path e.g. Career Ladder
  8. There is no Leadership career path e.g. Career Ladder
  9. Fast Tracking of Recruitment candidates, because they have a friend or your boss told you to do it
  10. Calling people “resources”, not people or engineers – More likely in companies with HR teams vs People Teams
  11. Leaders who say one thing to your face and another via email
  12. The churn rate (leaving the organization) of engineers and leaders
  13. The engineers do not feel like they are doing some interesting work
  14. Engineers do not know what their career path is
  15. Management that talks behind each others backs and not to each other
  16. Detached CTO
  17. People cannot give necessary direct feedback to each other

Books on People within Software engineering:

2. Process 

Bring consistency to delivery, find bottlenecks and remove them, keep evolving the processes

How do you organize people to be productive, keep getting better and produce high quality work? Effective processes will help your teams do their jobs with less confusion (and more shared understanding), faster on-boarding and a clear north in moments of chaos. Processes can also introduce a fairer approach. That said, effective processes need to evolve/change and they should be versioned.  They will sometimes get in the way, and maybe they should and maybe they should not. That’s where management decides.

  • How do you drive productivity? e.g. Agile/Waterfall,
  • How much time do engineers spend in meetings vs coding? How do they code without interruption?
  • How do you ensure improvement i.e. kaizen or reflection (in yourself and your teams)?
  • How is your tech debt approached?
  • How do you measure your platforms performance?
  • How do you interact with Product and Customers?
  • How do you evaluate different technologies?
  • How do you know when there is an incident? and what to do?
  • How do you release your software to production?
  • How do you ensure software quality?
  • How good is your interview process?
  • How do you reward e.g. promotion, merit increase? How often?
  • How good is your documentation?
  • How do teams share the work they are doing?
  • How do you protect time for you to do your job(s)?

Anti-patterns to look for:

  1. No budget
  2. No tests
  3. No Production Support
  4. Teams with a lot of manual work that can be automated
  5. C Suite does not understand what Tech Debt is and what the platform has to fix
  6. Takes weeks to release code
  7. A poor on call system with too few people on call
  8. Teams are bigger than 9 engineers

Books on Process within software engineering:

  • The Goal: A Process of Ongoing Improvement
  • The Mythical Man-Month by Frederick P. Brooks Jr.
  • Lean from the Trenches: Managing Large-Scale Projects with Kanban by Henrik Kniberg
  • Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin
  • The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim

Why Not?

3. Product

Know your customers and deliver what solves their pain

The level of product involvement for Software Leadership will differ by organization. Regardless, knowing your products will help you do a better job.

  • How do you know what causes your customer pain?
  • What is the Product Vision?
  • Who are your competition?
  • What is the plan to get MVP or the next chapter of your product?
  • Where do the UX/UI designs come from?
  • How are you going to make money?
  • How do you work with Sales, Marketing?
  • How do you manage Releases with Customer support?
  • What is your churn rate of customers and why?
  • What do customer most want to buy of what you sell?

Anti-Patterns to look for:

  1. No research, all opinion and anecdotes
  2. No researchers – Product, Business or UX
  3. Product Design/UX/UI is not valued
  4. Designs are not tested with customers, before coding
  5. Engineers do not know who their customers are
  6. Big Product decisions are not transparent
  7. An over reliance on numbers to make the case
  8. An under reliance on numbers to make the case
  9. No innovation
  10. Too many products/features vs focused
  11. The acceptance criteria for stories/features are weak or do not exist
  12. There are no Business analysts/researchers supporting Product Owners
  13. No balance between building features and building a reliable platform

Books on Product for Software engineering

4. Technology

Create great features, Know how the features are used, Manage your legacy products and Build a better platform. See where different systems could work together or be the same. Be able to compare technologies and understand the best fit for their problem.

  • How well do you know software, hardware and its organization and implementation?
  • What are the pros and cons of each domain of your platform?
  • How do you evaluate the technical skills of your engineers? How does this compare to your interview process?
  • How do grow technical skills in your engineers?
  • How good is your system design?
  • How do you improve the performance of your platform?
  • How do you keep your platform secure?
  • Can you code? Without blocking your team?
  • How well do you know the architecture?
  • Do you know the tools your business uses?
  • How do you keep up to-date with changes within the software?
  • How do you push your technical knowledge? e.g. what is next?
  • How do you balance features been built with increased stable platform?
  • Do you have skills within the team to support and progress the technology?

Anti-patterns to look for:

  1. No architectural vision
  2. No innovation
  3. You build everything yourself.. run, run now
  4. Less than 30% of engineers’ time is allocated to Tech Debt or there is no platform/core teams
  5. Your Databases are important to you and you have no one who is an expert in DBs e.g. a DBA
  6. Your UI/UX is important to you and you have no designers, UX Researcher or Front end Engineers
  7. You have no clear vision for each of your platforms e.g. Web and Mobile. I see a lot of companies have a poor Vision/Strategy for Mobile unless they are only Mobile.
  8. There is no plan or team supporting APIs
  9. You only have junior engineers or engineers who have only worked on one codebase
  10. You are building for scalability before you know what your business is
  11. Ratio of Engineers to QA/Test is greater than 3:1
  12. You have a small Mobile team (depends on the business)

Books for Technology in Software Engineering:

One of my book shelves

The balancing of Human, Process, Product and Tech

The order of importance of each of these areas depends on the culture, people and things you need to fix/upgrade/patch. Often if one is under-performing then the others will hurt as well. If you processes are weak, then knowledge is likely to reside in a few people who will leave (because they are overworked), which will be a hard hit for the organization and remaining people. If Technology is weak then your platform is likely to go down often, you could lose data, and it can be hard to add extra features. If your people are not invested in, or worse you hire the wrong people, they will leave. And finally if your product is not understood, your customers leave and no one has a job.

Whilst I have focused this blog on Engineering management, do not be mistaken that I do not fully value a technical career pathway. It is essential for allowing full growth of the majority of engineers, a healthy codebase and timely product release.

Why am I a Software Engineer Leader?

  • I love helping humans reach their potential
  • I love technology and ensuring it is doing the right thing
  • I love solving problems with other problem solvers whether they be engineers, product, designers or customers
  • I love the creation of a hypothesis and figuring out if it is true, and if not toss it away and move to the next
  • Understanding complexity to a level that you can explain it to anyone
  • Looking around corners and guessing what the future options are
  • Growing people to be better problem solvers, able to drop ego and traverse through multiple science experiments and be good people to work with
  • Solving tough problems that hopefully help people

Other perspectives

Microsoft Perspective

What Makes a Great Manager of Software Engineers? Microsoft

Googles’s’ Perspective – Project Oxygen

  1. Is a good coach
  2. Empowers team and does not micro- manage
  3. Expresses interest/concern for team members’ success and well-being
  4. Is productive and results-oriented Is a good communicator
  5. Helps with career development
  6. Has a clear vision/strategy for the team
  7. Has important technical skills that help him/her advise the team

D. Garvin, A. B. Wagonfeld, and L. Kind, “Google’s Project Oxygen: Do Managers Matter?” Harvard Business School Case 313-110, Tech. Rep., 01 2013.

My perspective

  • Facilitates a team vision with the team
  • Achieving collective support in multi-stakeholder environments
  • Discerning and prioritizing diverse stakeholder needs
  • Reconciling differences and presenting a unifying vision
  • Achieving buy-in and support for complex projects and programs
  • Leading in a multicultural environment
  • Creating a motivating environment
  • Influencing the team drive to act in support of mission, goals, and technical execution.
  • Good with Feedback and constructive conflict
  • Managing conflict and negotiations
  • Achieve Leadership and organizational alignment – Values, Vision and Mission

I do not believe my view is the only one, here are some others:

Leave a Reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. ( Log Out /  Change )

Cancel

Connecting to %s