Engineering Organization Objectives
This article is a result of me a couple of times joining new companies in a CTO position and trying to answer some important questions I was asked during the first few months by my colleagues.
Decision making, trust, transparency
The picture shows how the organizations (including Engineering) should be acting when it comes to trust/check and authority of making certain decisions.
Access to the information gives the most power to a decision-maker. The ability to trust the team under you is the most crucial in any business. But what does trust mean? How to establish that bond?
Well, this is another big topic that is hard to cover in few words, but essentially two persons have trust when they share values and abilities to communicate on the same level of EQ. Once you and your counterparty realize that all the decisions any of you would make are based on the same set of values, you can easily start delegating and accepting the decisions are made without you contributing.
Trust here is acceptance of decisions made by someone else, given that “someone” has a better context (than you do) to make a call.
Context equals information in the statement above. Hence, it means the organization’s ultimate goal is to give as much context as possible to all individual contributors to make proper conclusions and decisions on top of those.
Here are some examples of information that I usually see organizations are failing to provide to Engineering departments in particular:
- OPEX and CAPEX(see Capital Expenditures vs. Operating Expenses)
How much money the organization spends on items like Infrastructure, SaaS, rent of data centers, etc - Incidents and impact on the business
Once people see how much the company loses due to downtime or an outage, people will make much better decisions. Not all problems to be addressed, but some to be resolved right now. - Headcount (HC) expenses
Yes, this is a touchy topic for many organizations, but somehow, the leaders/managers should understand what resources they have and how to utilize them. Metric can be not in monetary terms but in units that would indicate the relative value of the whole team comparing to the rest of the company HC.
The data-driven and economic-based decision-making process is straightforward and has to be done by each individual in the company. Not “we have an SOP”(you need to know when to go wild), not “I was doing this before”, not “I was told”, not “my manager is the boss” — only data-driven decisions.
If you are a manager, your ultimate goal is to find and hire only people you would trust in all sorts of situations. Always try to hire a better version of yourself in a specific area or domain. Always aim for someone who can potentially replace you in a few years if (for some reason) you will stop your development.
What if you already have a team and need to work? Nothing is unchangeable! You still have to work with individuals who you can’t fully trust and improve your relationships. This process is emotional and resource-heavy that requires both side’s commitment to finish and realign on values, goals, and reasons.
OKR framework and roadmaps
The biggest power of the OKR framework in planning is bi-directional(top-down and bottom-up) Objectives and Key Results alignment. Team leaders should be mature enough (and you have to allow them this space) to dedicate some time in the upcoming quarter for the projects that the team thinks should be delivered (legacy, architecture, etc).
Balance of the KR in your final plan coming from you, your teams, and your leader will always depend on many factors including the maturity of the company, the scale of the business, trust management have in teams, and freedom that is adequate for a certain type of the business.
My ideal scenario when the team is creating 50%+ of my KRs for each quarter — the rest comes from me and the CEO/Executive Committee
Now you have direction. Time to get the plan that would include resources, timelines, relationships between the projects. The best way to do it is Gantt Chart.
No one is claiming the plan should be always 100% correct and updated, BUT that gives you basis for the rest of work and cross-team communications as well as the escalation of any unexpected outcomes.
You also may be interested in WSJF framework to build roadmaps.
There are many practices to build longer-term plans but the idea is always about maximizing outcome while minimizing resources that you have to spend.
Outstaffing and outsourcing
Once there is confidence in the management layer of the team (Directors, Heads, TLs), the company should be able to engage external parties to fill gaps and speed up projects. External resources can be used as individual contributors injections as well as entire teams reporting to a manager (Director, Head, VP depending on size of the team).
Depending on the situation in the Company, it can be risky to involve a third party to address critical issues or projects, as that dependency can become a sort of “vendor lock” where the ability to take over the systems back would not be realistic. Of course, those problems can be resolved contractually, but there are no obligations for any 3d party outstaff company to continue rendering service beyond already paid/agreed on.
Ownership and development automation
“You build it, and you run it” is the essence of ultimate ownership in IT. You can apply it to any level of the “good” organization. Founders — you build your company, you run it(laws, gov. Relationships, investors); CEO — you build the executive team, you run them(Vision, Objectives, Direction); Tech-manager — you build system/app, you run it (metrics, Scrum, motivation, technologies); Engineer — you build code/service, you run it (tests, prod incidents, bug-fixes).
To have this ideology in action, there should be an environment to have the ability to “run it”. For any engineer, there should be a clear pipeline and understanding of how to create some code, test it on a local/remote environment, contract with the Infrastructure layer(docker, helm, .war), monitoring and Alerting system, etc.
So the meaning of the ideology “You build it, you run it” becomes a little bit trickier and forces you to build this environment as well. Otherwise, how can you run that all? Not necessarily you have to do it by yourself. Still, you should always be ready to raise the concern, add an RFC and (if required) modify the existing setup with the best engineering practices accepted by the industry.
Minimizing dependencies to another team helps squads to run fast end efficiently. Bureaucracy is born in the dependencies clew, so try your best to avoid dependencies:
- hire required individuals who can pick up technologies fast regardless of stack
- learn new technologies by yourself (it will be slower in the beginning only)
- dedicate “champions” of certain technologies within teams as well as for specific activities (Security, Compliance, SRE/it-ops)
Automate all routines, automate your tests, automate security controls, automate the provisioning of employees, automate yourself (if possible).
Whenever you do something manually(apart from writing the code), start asking yourself — “does it make anything better in the long run?” Apparently, all IT giants try to build environments where there are automation QA specialists and automated tests, semi-automated production delivery, comprehensive monitoring, and alerting system that automatically does switchovers and failovers.
Less friction environment has — more interesting is to work there and focus on something that makes the world a better place — deliver products.
Product development
The product manager is responsible for timelines and economic reasons for developing the product/project. Technical Leader and eventually whole team is responsible for quality and security of the system they develop. TL and a PM should be aligned on the estimates based on what the whole team is saying, so the Product team can have a clear picture of what and when will be delivered.
The ultimate goal of a PM is to explain as deep as required by TL and the team what does the customer thinks he wants and what we can build to satisfy the desire.
Ultimately TL is the one who should own and be accountable for how the code/system works in production for the end customer.
Good questions to ask yourself(if you are TL or engineering staff) before shipping a feature:
- Does it have bugs? Is it secure? How did we check it?
- Will it work in 2–3–7 years? Will it work under load, and how am I gonna scale it? Where is the limit of scalability? Is it enough for the customers? Stress tests, integrational tests are set to be run periodically?
- Do the customers like it? If not, why did we deliver it to them?
Titles, functions, and Ranks? Impact and Objectives!
Organizational structure is good for some things, in my opinion: information flow, reasonable objective boundaries (i.e., the Security team should mostly work on security….but also fine if they need to do relevant Compliance or engineering work), mentorship and growth support. It’s ok to have a title or a rank in a company(or in any group), but what is priceless to have is the observable impact you are making on the product, team, and society. Focus on objectives you think are important, and regardless of your title, you should be able to drive them. If the objectives are correct and ambitious — people will listen to you and follow your lead; otherwise, you would have to think again and start over with new objectives and initiatives.
When people associate your name with the impact that you’ve done on the company rather than to an area of responsibility or title, that’s the success you should only wish for. If you are successful within the company, then the company is successful in the business. If the company is successful, then for sure, it will appraise, promote, cheer the people who helped to get to the top — regardless of titles!
Never focus on the function that you think you should do in the Company — instead, focus on the objectives that are important to your team, department, or the whole organization. If it takes to execute someone else’s “function”(assuming the company lacks resources or that one’s priority is different) — so let it be, and it won’t hurt anyone. Later you can align with that person and make the function to be facilitating your needs — but never be blocked on the way to your target/objective.
Time tracking VS Results
Rather than focus on the time, you spent in front of the screen, focus on the results you deliver. Results and effect your work has on business(proved by some data) will always be appreciated, unlike the time you spent in the motion (see Motion vs. Action). This fundamentally implies absolute trust in each individual who is working remotely or from the office.
Trust and reputation are the most valuable assets you hold as an individual, which is so hard to gain and freaking easy to lose. Be careful and mindful of this.
Work smart! Not hard
I’ve seen it many times — people are working so hard that they are forgetting why they are actually working at all. Ever seen a manager answering emails at night? Or an engineer spending overtime to make stuff working?
I’ve also seen disciplined and organized guys running huge initiatives without the effort of an army of “biz-zombies”(underslept people driving the business initiatives).
Don’t work hard! Always work smart and be mindful of time(the most precious resource on Earth)! There are multiple studies that show how the business can be negatively affected by people who are burned out or lacking sleep. I recommend reading the book “Why We Sleep: Unlocking the Power of Sleep” which is both useful for leaders and personal life.
The Pareto Principle, specifies that 80% of consequences come from 20% of the causes, asserting an unequal relationship between inputs and outputs.
My recommendations here would be:
- Make sure you(and your team) have focus on the most important items and don’t try to solve all the problems of the world
- Don’t fall victim to such a common mental trap: “full schedule brings life security”. It does not! You are just losing yourself in the limbo
- Maximize the efficiency of your time by focussing on the top important things. Remember and use Pareto Principle
- Have time to think. Yes, just dedicate time in your corporate calendar to think and reflect on the current situation and your health, business trajectory and your kids, budget for your data center, and hobbies you want to start. Business and personal concerns are always interconnected.
Failures and Incidents
If you are not failing, maybe that’s because you are doing nothing. Personal failures, as well as business incidents, are inevitable. Don’t be afraid of failures but always try to avoid them by making the right conclusion from your experience and the skills you have so far.
It is like riding a bicycle. You don’t want to fail, but still, you are there on the track. You are conscious and wearing a helmet to be protected. You can do this because you failed many times when you learned how to ride in full gear. Do you want to do a new trick on your bicycle(maybe BMX)? Same journey try-fail-try-fail-…-try-succeed. There is no other way for this! And never will be.
If you are afraid to look absurd when you are failing, or being wrong, or creating a business incident, remember this — everyone is failing but the ones who see in these failures opportunities are succeeding after all. And people who know how to succeed through failure will never laugh at those who are on their path to success.
Learn how to Learn
If I need to pick the most important skill I have to have — I would go with the ability to learn and absorb new knowledge. Every 10–15 years, the world is changing almost wholly, and you will not be able to fit it unless you are constantly evolving with it.
- Find the best way to learn for yourself: books, videos, conferences, mentors, articles, podcasts…
- Find the attractive area to learn about: IT, Psychology, Cooking, sports, philosophy…
- Apply your studies to make the world a better place. And the better place would treat you better for sure, which would create a positive feedback loop for this algorithm!
Studies show that practically anyone can learn to do anything as long as they have enough motivation. There are plenty of books on the market about self-motivation and making this motivation work for you. Atomic Habits, Ego is the enemy are the recent ones I liked.
Cognitive load and work-life balance
Each team should own its domain or few and be segregated with defined and clear boundaries in git-repos(should not have shared codebase), Interfaces (communicate only through APIs with other services), queues(or communicate using event bus), etc. from the other teams. That implies (a) the ability to work independently and (b) focus on certain problems within their domain(s). Temporary teams can have paired “project teams” to solve a certain cross-team problem but ownership of the service, code, product remain with a single team.
Team Topologies is a nice book about Conway’s Law and how to apply it to management in an organization.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure
— Melvin E. Conway
The clear and limited scope of the job benefits both an employee and the Company. That increases productivity, focus, quality, user experience, speed of delivery. This also eliminates burnout frustration over many responsibilities and increases employee happiness.
Segregated domains are not contradicting objective focussed teams’ approaches but balancing it on the other side. None of the approaches, “cross-domain objective-driven” and “only domain-focused” teams, are ideal. The organization should find the balance between them based on internal trust, external factors, and resources the company has.
Architecture and changes in its design
RFC (request for comments) and open-source practices can be some of the best ways of making big changes in the design of the architecture. If any team member sees the need for a change, she can create a new request, and others should be able to comment and suggest improvements to the offered solution.
Architects are supposed to be responsible for researching (making tests, compare, identifying pros/cons) and developing PoC for some new solution and then advising other stakeholders and engineering heads/managers for using this or that approach.
Good examples of the RFCs in modern IT are presented in Golang and Kubernetes communities.
Reporting lines, leadership, teams
If you are on the right trajectory to your goals, aligned on values the Company has, grow and help to grow others in the team, motivated and motivate the people around, make your decisions based on your professionalism and data on hands, recognize weaknesses and endorse blameless discussions…if you do all these, how does it matter who reports to who?
Leaders should not enforce decisions, use their veto right or be arrogant. But they should quickly identify the problems and highlight them for the team, consider the team as a team and not a set of individuals, see toxic elements in the team and get rid of them swiftly, offer mentorship but not use knowledge for making direct calls on problems, allow where possible to fail and learn from this.
Never aim to be a boss. Always try to be a leader. And that can be done regardless of your rank, title, or level of acknowledged accountability.
Cadence defines speed
Like a cyclist always working on cadence, which defines her speed, the teams should keep in mind how the length of the iterations affects their performance. Some teams should work in 1 or 2-week sprints, while others should use kanban and focus on the speed of the tasks going through the pipeline. The leadership role is to steer the wheel all the time and keep an eye on metrics and the cycle progress, whether it’s a weekly sprint, annual strategic, or quarterly tactical cycles.
Leadership/Management cycles (in my opinion) should be week-long, which gives enough granularity to make corrections and/or manage risks if any are foreseen. The usual technical leadership “package” of reporting is:
- Progress against the planned OKR (roadmap with dates)
1. Was planned and done on the last cycle
2. Was planned but not done on the last cycle (and why?) - Key metrics
- Highlights and roadblocks (dependencies, blockers, etc.)
Leadership style
Leadership style is a “classic” question all leaders are getting on the interview or from subordinates.
Here is my answer, which is somehow a summary of the previous paragraphs:
- Ultimate trust and ultimate transparency is the way to scale
- Partnership and mentorship to help your peers and yourself to grow (instead of Management and “Boss-ship”)
- Metrics-driven mindset. I need to see the data all the time otherwise it’s hard to do good decisions
- Motivate to grow and don’t build submissive relationships
- Failure-friendly and Blameless environment with straightforward discussions/feedbacks (Sandwich Feedback method is not a good way, try Stop, Start, Continue approach)
- Hire people that can be your own extension and smarter than you in certain areas/domains
- S.M.A.R.T criteria in goals and projects
