Your seniority is a lie
Seniority formula
There has always been a rush towards getting top-edge seniority levels such as senior, principal, architect, etc. For some reason, it seems to be strongly 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 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 improve. 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 promotion. For these people, changing the company often means downgrading from senior to junior level of seniority.
Disclaimer
[…], do not get offended.
Focus on the right thing
If being the top-labelled person in a room does not help achieve the goals, 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 unexpected project, 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 to achieve the team’s goals instead of ticking the next requirements set by the 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 a 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 I shared with the development team. The reaction I got was pretty offensive cause I was not teaching developers these methods in a 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 of using UX techniques with customers, 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 open the new decade, they point to the design. I agree. However, who will be the driver of that?
Nowadays, 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. The same happened with software development when we got much more high-level programming languages and frameworks that may generate working solutions for us in a few 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; if they try to do that, they will most likely 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 for 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 valuable and lightweight enough for them to use these techniques in daily work. If I asked software engineers who love to live in a basement to start the customer journey mapping by 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 like to understand the world through this model. It also applies to understanding the learning curve of 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 you something, do not tell them 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 found out that the presentation of sequential events on a 2-dimensional surface helps them 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 you are the UX Designer and 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 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 getting rid of the IFs, WHILEs, and 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 in 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 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, there is a famous saying: 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 fan of engaging the QA Engineers at the beginning 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 of 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 performed 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 a manual tester to an 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
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. Getting to know the language and programming process is a must at the beginning of the career. 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 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 you can achieve is getting the right skillset to bring the brownfield project up, and make a diamond out of it.
Suppose your company selects you to start a new important project. After a year, you blame the others, business, and deadlines for its poorly delivered business value, high coupling, low quality, or whatever. In that case, 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 work 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 converting into a project management role, recruiters called me back to ask if I had 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 that 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 Scrum is a methodology which requires adjustments. It does not when you want to use Scrum for its purpose. I also do not think that Scrum is the only one methodology you can pick - personally, I prefer mixing Scrum, Kanban, Shape Up and knowledge from PMBOK.
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 their values.
The result 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.
What can you do this week? Try to get into software engineer’s shoes by finishing a short Django Girls Course.
Raise your level of accountability. Do not just evangelize.
Calling to Business Analysts
No good news. If you are not 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 or Product Manager.
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 ensure 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 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 projects, which I mean 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 they often become a communication proxy between team members. They create the illusion that 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 creates a factory of so-called senior developers who have never experienced real business accountability. They deliver Jira tickets.
One of the typical responsibilities of a project manager is to provide 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.
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 for 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), and learn the 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
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 some workflow management framework.
All of these things bring us to the state when we all work agilely, 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, providing tons of information for the next stage.
Who cares what you deliver and how good it is if your colleagues are not using it to achieve a common or 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 your team members specialize in. Just to get more respect for them. We tend to advise others without knowing why and how they operate.
Software development is becoming 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 are often the simplest ones.
Do not create lots of accidental complexity 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, and 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 greatly, 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, observability, 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 what 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 an investment. After building the whole business concept around that, we create the product. We try to optimize everything 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.