Seniority formula

There has always been a rush towards getting top edge seniority levels such as senior, principal, architect, or so. For some reason, it seems to be strongly being driven by Dunning-Kruger effect, which is getting so much confidence about our skills way too early. People tend to go for beautiful email footer titles backed up by over-confidence, which slows their progress down unless they meet a good mentor, who guides them through that process.

A few years ago, I came up with my understanding of the seniority formula, which is contextual only for a company that you work for.

Seniority = Problems solved / Problems created

Not so complex. However, I got tired by too early promotions of the people. In fact, they are the ones who are being hurt the most.

That is so cool to support ambitious junior specialists', who want to get better. Even after-hours, not getting paid for it. The worst thing you can face in daily work is cooperation with senior specialists' affected by early promotions. Pretty often, for these people changing the company means downgrading from senior to junior level of seniority.

Disclaimer

[...], do not get offended.

Focus on the right thing

If being the top labeled person in a room does not help to achieve the goals, then what does? Start with the question of what the goal is.

In the software development industry, we eat fresh fruits, drink delicious coffee, play PS4, and enjoy daily work. That gives us an environment where we may focus on making fun out of our work every day and being selfish about our duties. If we get some not exciting project, then we complain to our managers. If we work on a brownfield project, then we complain because we want to start something new on a greenfield, even when we are the ones who made the grass that dirty.

But hey... we are getting paid for the work. Maybe we should focus on the thing that we are getting paid for? As software development is a team sport, in most cases, our goal is to become a part of the team. Maybe we should aim for achieving the team's goals instead of ticking the next requirements set by competency matrix to the seniority level in our job title? Personal growth will follow.

Prioritising self-expertise

Some time ago, I was trying to convince the group of software engineers/developers to use more "UX" techniques. We spoke about stuff like user story mapping and customer journey mapping. They kind of like that.

After some time, I asked one UX Designer for his thoughts on the topic, that I was sharing with the development team. The reaction I got was pretty offensive cause I was not teaching developers these methods in by-the-book style. That was true. However, that was never my idea to teach developers how to be a good UX Designer. If they would like to get the perfect knowledge in using UX techniques with customers, then they would probably become UX Designers.

A few days ago, a16z wrote an article about Investing in Figma: The Decade of Design. The so-called decade of design is just around the corner. However, how may our community achieve that? Does it mean that designers will become the most crucial role in creating solutions for the world? I am not so sure. I firmly believe, Figma was spotted by Andreessen Horowitz not because it is a UX Design tool, but because it is a collaboration tool.

At the beginning of the current decade (2011), they wrote a viral article Why software is eating the world. As we are about to open the new decade, they point to the design. I agree. However, who will be a driver of that?

In nowadays work, I see many UX Designers, who work like UI Designers. All the design software/tools are not very hard to use, and we experienced the hype for that. The same happened with software development some time ago when we got much more high-level programming languages and frameworks that may generate working solutions for us in a couple of minutes. There was a legendary video about scaffolding a blog in Ruby on Rails in just 7 minutes. That was a significant shift in the software development industry.

Assuming the decade of the design. Will the designers achieve that on their own? I think they cannot, and if they try to do that, they are most likely to fail. The answers are in Figma's subtitle, which is "Where teams design together ".

Let's get back to my story about UX Designer, who hated me about improperly teaching software engineers UX techniques. Hey... it does not matter if you teach someone your expert skills by the book or not. The thing that matters is if you can encourage people to find it useful and lightweight enough for them to use these techniques in daily work. If I would ask software engineers who love to live in a basement to start the customer journey mapping with feeling users' emotions by running the empathy map session, I would probably get kicked out through the window.

In Management 3.0 book by Jurgen Appelo, there is a model called The 7 Levels of Delegation. I am passionate about understanding the world through this model. It also applies to understand the learning curve of the people, just like in cooking. Junior cooking chefs require recipes. Advanced chefs are not able to cook anything delicious when following the recipe. You may understand the same thing through the Dreyfus model of skill acquisition, which suits even better in the described situation.

If you want someone to teach something, do not tell to do everything perfectly. Provide step-by-step instructions on how they can start using that today. The described software development team just after the workshop began using visual boards with sticky notes not because they wanted to do customer journey mapping or user story mapping. They simply found out that the presentation of sequential events on a 2-dimensional surface helps them to quickly discuss the ideas and business complexity. Technique by its name does not matter. The time for that will come. And after it comes... techniques will stop matter again because, at some level of expertise, all the techniques narrow your possibilities as an expert.

Calling to UX Designers

Assuming that you are the UX Designer and you want your team to achieve more. What can you do?

Focus less on user interface design and put more effort into information architecture, interaction design, rapid verification of the ideas, and visual collaboration methods. Try to sit together with software engineers and work with them daily. Show them more visual ways of thinking about software engineering. Guide them through the process of getting rid of the IFs, WHILEs, lambdas, and bring them closer to the whiteboards, walls, and users.

Stop thinking about your job as providing the "layouts" and user interfaces. Start being a part of the team on designing the solution by providing an understanding of the user's perspective. Maybe even let's take part of the responsibility of the project manager's because you will probably be better in many areas than he/she as a proxy.

Raise your level of accountability. Do not just paint.

Calling to Testers

The issue about testers is located in this job title's name. Tester is meant to test something, which already exists. That's a waste of money.

In security engineering areas, there is a famous saying nowadays shift left on security, which means to bring security engineering into the development process. Some people call it DevSecOps.

What if we could stop calling testers - testers, and start calling them QA Engineers? It is already widespread. However, even this title has already got negatively affected by the term "tester".

I am a big fan of engaging the QA Engineers at the beginning of the process of delivering each story. This way QA Engineers may focus not on testing the existing solutions but on the education of the whole development team on how to assure functional and non-functional quality in the system. The goal for QA role is to help the team to reduce the number of bugs that would appear in the columns located on the right side of a Jira board.

That may be achieved by pair-programming-testing between QAs and Software Developers. That may be achieved by listing down the acceptance criteria during the refinement process. That may be achieved by proactively improving the Definitions of Ready and Done. And as we think more about connecting the development teams with the business world - maybe it is an opportunity for QA Engineers to become domain business experts and internal advocates of our end-users?

What's the worst thing you may do? Think about your career path as going from being manual tester to automated tester. There is much more value in you.

What can you do this week? Ask a developer who you like to do a pair-programming session. Programming? Tester? Yes!

Raise your level of accountability. Do not just test.

Calling to Software Developers

Like four years ago my boss Piotr, during one of the project management training said,

Developers will code as long as possible; they chose that job because they love to code, and as they love it, they will keep doing that.

– Piotr, Rafal's Boss

Writing code by developers is the worst thing that they can do. That's a must at the beginning of the career to get to know the language and programming process itself. However, I wish every developer could meet on their career path the person who tells them what's truly important. The same effect may be achieved by getting very close to the end-users, which, unfortunately, does not happen very often.

Marty Cagan once said,

If you're just using your engineers to code, you're only getting about half their value.

– Marty Cagan

And, that's the case. Being a machine for delivering Jira tickets from left to right is the root of all evil.

A parallel example of that is thinking about the career path as:

• junior developers are usually getting some maintenance project,
• senior developers are usually getting a greenfield project.

This kind of seniors focuses on the wrong thing. The highest software engineering seniority that you can achieve is getting the right skill set to bring the brownfield project up, and make a brilliant out of it. If your company selects you to start the new important project and after a year, you blame the others, business, and deadlines for its poorly delivered business value, high coupling, low quality, or whatever - you are on the 1st peak of the Dunning Kruger effect.

If you are learning the next framework, think of how you can use the new knowledge to maximize the frequency of the deployments to production and reduce the failure rate. All of it by delivering "potentially releasable product" most of the time instead of accepting broken CI pipelines.

What can you do this week? Learn proper tasks granulation. Try to deliver value faster. Do not over-engineer things. Ask your stakeholders about project goals and try to encourage your team to work together on delivering its goals instead of maximizing the throughput of tasks done in the sprint.

Try to achieve the most by writing a few lines of code as possible or, in other words, by quoting the famous person...

Your job is to minimize output, and maximize outcome and impact.

– Jeff Patton

The decade of the design is just around the corner. You are one of the superheroes to run it. Do not get tricked by the word "Design".

Raise your level of accountability. Do not just code.

Calling to Scrum Masters

And here we are... sprints. For some reason, many Scrum Masters are very aggressive in evangelization. I do not find Scrum as an ineffective way of working. I think the opposite. Scrum and Extreme Programming have done more to Agile than any other methodologies. However, over time it becomes a buzzword for a bunch of invaluable certificates.

When I was finishing my software development career a few years ago, and I was converting into a project management role - recruiters were calling me back just to ask if I applied for a correct job position. To overcome it, I decided to pass the Professional Scrum Master 1 exam. I have never worked in the Scrum Team before. I opened the Internet. I spent 9 days reading about Scrum, and then I passed the exam for 93%. Does it make me a Scrum Master? Nope, but it quickly moved me to the first peak of the Dunning Kruger effect. I started realizing the basics of what the Scrum is all about, like three years later.

As a Scrum Master, you focus on assuring if the Scrum is understood and respected within the team and the organization. The worst thing you can do is to force everyone around you to work with the Scrum by-the-book by the first day.

I do not mean that the Scrum is a methodology, which requires adjustments. It does not. It is the most common problem why many people hate Scrum - they have never tried Scrum as it is described in a Scrum Guide, just because: " sorry, needed to adjust, we are the specific organization, one of its kind".

However, extreme Scrum Masters focus on their skillset - Scrum-evangelisation-skills. They ask teams to go 100% for that instead of helping the team to go through the long process of discovering and understanding Scrum and Agile by its values.

The result of that is using the half-Scrum as a set mechanics/framework for team collaboration. But... it is not that bad, far better than no mechanics/framework at all.

Being a blind person, who forces the team to use Scrum just because you are the Scrum Master, brings you and everything around you down. You convert your role from impediment remover into something strange because the process becomes an impediment itself, and you become an impediment.

I think the most significant change in my case was reading the book Coaching Agile Teams by Lyssa Adkins. I made all of the mistakes described in this book. There is a famous saying about learning from other people's mistakes. In reality, we mostly learn on our own ones.

What can you do this week? Try to find Agile/Scrum group in your city. Go out and talk to other people. Try to learn from their experiences. Listen more, speak less.

Raise your level of accountability. Do not just evangelize.

Calling to Business Analysts

No good news. If you are not a part of a big project, then start thinking about widening your role. Most BAs are likely to produce analytical artifacts that will be re-analyzed by the development teams, which is a waste of time.

Learn the basics of UX Design and programming. Think about being a Product Owner.

If you are on a big project, you can help a lot by managing the knowledge of surrounding essential complexity, which might be very useful for the team. The best thing you can do is to make sure there is a 2-directional communication channel between you and your colleagues. Ask them what you can improve in the artifacts which you deliver.

Raise your level of accountability. Do not just generate documentation and knowledge.

Calling to Project Managers

Pretty often, I am one of these. My understanding of project managers' role in most of the projects is kind of a... negative. It is like a self-hate of my person. I firmly accept the fact that project management skills are very needed. Mostly in big projects. In reality, most of the development teams, who say they work on a big project, work on small or medium size project in my understanding.

When we work on small or medium size project, which I mean is built around 3-25 people, project managers are (in my opinion) usually reducing the potential of the other roles. Project managers tend to take the "accountability" for the project's delivery, but pretty often, they become a communication proxy between team members. They create the illusion of always contact that one person because he/she takes accountability, and he/she must be informed, and he/she must decide. With that attitude, people start seeing the project manager in that way, and by doing so, they reduce the level of accountability in themselves.

It leads to creating the factory of so-called senior developers, who have never experienced real business accountability. They simply deliver Jira tickets.

One of the typical responsibilities of a project manager is providing the team with a sense of urgency. In many cases, when the project manager doesn't understand the business, not the technology - he/she creates an invalid perspective on that.

What can you do this week? If you spend 80-160 manhours on a project, try to think how you can reduce this time by 33% by setting the objectives for the team members and by asking them to take ownership and accountability on that. If you communicate your expectations, you will be surprised by the results they achieve and the progress they make in their careers.

Stop being a parent. Start being a partner.

In the meantime, take basic programming courses (e.g. Django Girls or Rails Girls), learn basics of UX, data analytics, marketing and techniques for splitting down the user stories. Do not do that to micromanage, but to raise your understanding.

Your seniority is a lie

All of the modern software development trends go towards "tech is a business" and "bring engineers and business together". UX Designers achieve that by applying Design Sprints. Software Developers use Domain-Driven Design and Event Storming. Product Managers think about Lean, A/B Testing. The development phase is built around the Scrum framework.

All of these things bring us to the state when we all work in an agile way but we forget to work as a team. That creates a cycle of agile phases in a waterfall process. Everyone wants to do their best, and everyone provides tones of information to the next stage.

Who cares what you deliver and how good it is, if it is not being used by your colleagues to achieve a common or a shared goal?

Team's versatility is the new North Star

Your team cares. And they need you.

The purpose of this article is to encourage you to widen your perspective from just specialization expertise to getting at least a basic understanding of the skills that your team members specialize in. Just to get more respect to them. We tend to improve others without prior knowledge of why and how they operate.

Software development becomes more and more complicated. Not only because of technologies and market requirements. We focus too much on using the new tools and our skillsets than on delivering the best solutions to existing problems, which pretty often seem to be the simplest ones.

Do not create lots of accidental complexity just to get a better job title.

Stop being senior, start being junior

Becoming a senior specialist with two years of total experience is a commodity. However, there is an excellent interpretation of a few different phases in seniority. Let's take software developers as an example.

First, we focus on understanding the programming languages, tools, techniques, design patterns, message brokers. We learn Scrum. We get the designs from the designers, and we can use Zeplin or Figma. We become senior software developers.

Then, we realize that quality matters a lot, and we become junior software engineers. We start getting more into software craftsmanship. We value documentation, security, handoff process, bug fixing, migration plans, shortening cycle times, fastening delivery to production, reducing the failure rate, or optimizing time to restore. Learning from Flickr, we try to maximize deployment frequency. We value our business stakeholders. We do event storming. We become senior software engineers.

Then, we realize that the blind delivery of the code is not the thing that matters, and the best code in the world is the one that's never been written. We become junior product engineers. We realize that the code developed within' the specific projects is just a cost for the company, which some people call investment. After building the whole business concept around that, we create the product. We try to optimize everything that we do to deliver value for the clients as soon as possible. We stop calling ourselves "we and them", we become a product team, built of the product engineers, where the seniority does not matter.

Stop being a senior developer. Start being a junior product engineer.

Resources

• [1] Dunning-Kruger effect, Wikipedia
• [2] Investing in Figma: The Decade of Design, a16z Blog
• [3] Why software is eating the world, a16z Blog
• [4] Management 3.0, Jurgen Appelo
• [5] The 7 Levels of Delegation
• [6] Dreyfus model of skill acquisition
• [7] Shift left on security, Security Round Table
• [8] Coaching Agile Teams by Lyssa Adkins
• [9] Django Girls, Two Days Long Programming Tutorial
• [10] Rails Girls, Two Days Long Programming Tutorial
• [11] awesome-eventstorming repository
• [12] No Silver Bullet, Frederick P. Brooks, Jr.
• [13] Velocity 09: John Allspaw and Paul Hammond, 10+ Deploys Per day